Also auf meinem ReadyNAS habe ich immer noch dieses Problem. Auch mit
aktuellem 7.3.3 installiert. Konnte noch nie einen kompletten Scan
durchlaufen lassen. Log spuckt dasselbe aus wie in Post 1.
Wäre sehr froh um eine Lösung.
--
waleburg
---
Also bei mir funktioniert das seit den letzten Updates immer wunderbar.
Danke an alle, die mtgeholfen haben!
--
Sunnysekot
Sunnysekot's Profile: http://forums.slimdevices.com/member.php?userid=20990
View this thread: http:
mherger;394561 Wrote:
> Ok, und unterdessen haben wir einen anderen Patch drin, welcher dieses
> Problem beheben sollte. Bitte testet doch mal den aktuellsten 7.3.3
> Build.
Ach mit meine QNAP funktioniert es wieder gut.
Vielen Dank!
Theo
--
Tejay
---
Rescan mit Version: 7.3.3 - 24925 funktioniert auf Synology DS107+
wieder.
Danke!
mherger;394561 Wrote:
> Ok, und unterdessen haben wir einen anderen Patch drin, welcher dieses
> Problem beheben sollte. Bitte testet doch mal den aktuellsten 7.3.3
> Build.
--
Uwi
Ok, und unterdessen haben wir einen anderen Patch drin, welcher dieses
Problem beheben sollte. Bitte testet doch mal den aktuellsten 7.3.3
Build.
--
mherger
Michael
-
http://www.herger.net/slim-plugins - AlbumReview, Biography,
M
> Michael, sagst Du hier ab wann das in den Builds voll integriert ist
> und nicht nach jedem Update erneut manuell eingebaut werden muss?
Es _war_ drin. Wir mussten es wieder raus nehmen, weil die Änderung auf anderen
Systemen (Debian basierend) zu Abstürzen führte. Siehe auch
http://bugs.slimd
mherger;390017 Wrote:
> > Das wars!!! Fehler aus meiner Sicht bereinigt!
>
> Danke fürs Testen! Die Änderung sollte im nächsten "Build" mit drin
> sein.
>
> Michael
Also, ich habe auf diese schönen Meldungen hin gleich mal
7.3.3-24850 installiert in der Annahme, dass das Problem dann mit dem
n
mherger;390017 Wrote:
> > Das wars!!! Fehler aus meiner Sicht bereinigt!
> Danke fürs Testen! Die Änderung sollte im nächsten "Build" mit drin
> sein.
> Michael
Habe jetzt auf meiner Synology DS107+ die zwei Files my.tt und
MySQLHelper.pm
manuell angepasst und siehe da, jetzt wird die Datenbankb
> Das wars!!! Fehler aus meiner Sicht bereinigt!
Danke fürs Testen! Die Änderung sollte im nächsten "Build" mit drin sein.
Michael
___
slimserver-de mailing list
slimserver-de@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/slimserver-
Das wars!!! Fehler aus meiner Sicht bereinigt!
Die Datenbankoptimierung 2. Durchgang ist sauber durch. Ich hab nach
"neuen und veränderten Musikstücken suchen" gewählt, also keinen
komplett neuen Scan veranlasst, der ja vorher schon lief. Keine
Einträge in scanner log oder server log, alles saube
> Ich könnte das heute Abend mal testen.
Das wäre super!
> Wie muss ich den Patch denn einspielen? (ich hab den patch als
> tmpdir.diff gespeichert)
Eigentlich reicht es, die beiden mit einem + markierten Zeile in die
entsprechend Datei an der entsprechenden Stelle einzufügen. Die Dateipfade
s
Ich könnte das heute Abend mal testen.
Wie muss ich den Patch denn einspielen? (ich hab den patch als
tmpdir.diff gespeichert)
Viele Grüße
Ralf
--
rspieckermann
* QNAP TS-509 Pro 4GB RAM 5 Seagate 1TB : SwapToUSB : SSOTS 1.15 :
SqueezeCenter 7.3.1 : TwonkyMedia 4.4.9
* Plugins: AlbumReview :
Wenn ich am Wochenende Zeit haben werde ich den Patch mal ausprobieren.
--
msrberlin
msrberlin's Profile: http://forums.slimdevices.com/member.php?userid=21764
View this thread: http://forums.slimdevices.com/showthread.php
> die Änderung habe ich jetzt bei zwei Konfigurationen durchgeführt.
> Danach war das Problem weg. Einen Bug Eintrag gibt es glaube ich noch
> nicht.
http://bugs.slimdevices.com/show_bug.cgi?id=10840 - habe den mal eröffnet. Habe
da auch einen Patch dran gehängt, welcher SC so ändern würde, dass
Hallo,
die Änderung habe ich jetzt bei zwei Konfigurationen durchgeführt.
Danach war das Problem weg. Einen Bug Eintrag gibt es glaube ich noch
nicht.
--
msrberlin
msrberlin's Profile: http://forums.slimdevices.com/member.
> sollte alles funktionieren. Ich habe das ganze auch in meinem Blog
> dokumentiert: http://www.schirmer-online.de/2009/01/s ... reinigung/
Super! Vielen Dank für diesen Beitrag. Du kannst also bestätigen, dass die
tmpdir Einstellung das Problem des Crashes ist? Ich glaube wir sollten die
Konfig
Hallo,
ich hatte bis vor kurzem das gleiche Problem. Die MySQL Version von
SqueezeCenter benutzt eine andere Konfigurationsdatei. Die Datei heisst
my.tt. Auf deinem System sollte die Datei im Verzeichnis
/share/HDA_DATA/SqueezeCenter/MySQL liegen. In dieser Datei die
entsprechenden Änderungen für
Ich habe die Perl Source Version: 7.3.2 auf meinem QNAP installiert.
Heute habe ich eine rescan getan, und ... SC ist nach 00:18:34
beendet.
Die gesamte Zeit bleibt bei 00:18:34.
Danke Jungs.
Theo
--
Tejay
Tejay's Profil
Uwi;383240 Wrote:
> Habe grad ferienhalber keinen Zugriff auf meine Squeezebox aber in einem
> früher in diesem Thread geposteten Logfile von mir sieht man:
>
> DBD::mysql::st execute failed: Incorrect key file for table
> '/tmp/#sql_951_0.MYI'; try to repair it at
> /volume1/SqueezeCenter/CPAN/
mherger;383033 Wrote:
> >
> Das gleiche Problem oder das gleiche Symptom? Siehst du denn dieselbe
> Fehlermeldung im server.log File?
Habe grad ferienhalber keinen Zugriff auf meine Squeezebox aber ich
meine mich zu erinnern dass ich auch sowas in der Art im Logfile sehe:
"Incorrect key file fo
> Nochmal zum festhalten, das ist nicht nur ein QNAP Problem. Bei
meiner
> Synology DS107+ hab ich das gleiche Problem.
Das gleiche Problem oder das gleiche Symptom? Siehst du denn dieselbe
Fehlermeldung im server.log File?
> Gruss aus den sonnigen Bergen (ja, der war gemein...)
Hehe... was mei
> Nochmal zum festhalten, das ist nicht nur ein QNAP Problem. Bei meiner
> Synology DS107+ hab ich das gleiche Problem.
Das gleiche Problem oder das gleiche Symptom? Siehst du denn dieselbe
Fehlermeldung im server.log File?
> Gruss aus den sonnigen Bergen (ja, der war gemein...)
Hehe... was mei
mherger;379471 Wrote:
> Ich habe hier keine QNAP rumstehen. Fall jemand von euch bereit wäre,
> mir Zugang zu seinem NAS zu geben, damit ich dieses Problem untersuchen
> kann, so meldet euch bitte per mail an michael ät slimdevices punkt com.
Nochmal zum festhalten, das ist nicht nur ein QNAP Pr
Hallo allen,
Auf dem Englischen seite
(http://forums.slimdevices.com/showthread.php?t=56407) steht ein
vergleichbare thread. Nicht so ausfurlich wie bei Ihnen.
Michael, when Sie um den Ecke wohnen, hatte ich ihnen ein QNAP
gebracht.
Zugang auf meinem QNAP via das Internet is mich zu compliziert.
Ich habe hier keine QNAP rumstehen. Fall jemand von euch bereit wäre,
mir Zugang zu seinem NAS zu geben, damit ich dieses Problem untersuchen
kann, so meldet euch bitte per mail an michael ät slimdevices punkt com.
--
mherger
Michael
---
Hallo zusammen,
ich hab gerade auf Version 7.3.2.24498 (aktuelles Build) upgedated und
eine Suche nach veränderten Dateien gestartet und das Problem besteht
weiterhin, die Datenbankbereinigung 2. Durchgang läuft weiterhin.
Somit ist das Problem mit der Beta noch nicht bereinigt. Schade..
Übrige
@rossi
Das ist zwar sehr schön, aber unerheblich, weil bei ein kompletter
Neuscan sowieso immer funktionierte. (Da ist keine
2.Datenbankbereinigung nötig!)
Was nicht ging ist dann eine suche NUR nach neuen und veränderten
Dateien.
Hast Du das schon probiert rossi? Geht das jetzt mit der neuen
Ver
@sunnysekot
Interessant! Jetzt kann ich mitfühlen! Tragisch! ;-)
Spass bei Seite: Gestern habe ich auf die aktuelle 7.3.2 24475 clean
upgedated (komplett mit SSOTS löschen, neu aufspielen und einrichten).
Das Ergebnis: Nach 3,5h war der Scan fertig (und zwar komplett!) incl.
einer Datenbankbere
rspieckermann;378927 Wrote:
> Hallo zusammen,
>
> bin gerade auf diesen Thread gestoßen, da ich das gleiche Problem
> habe.. (also dass der 2. Sortierungslauf ewig dauert mit entsprechenden
> Einträgen im Scanner log)
>
> Dabei hab ich ein wenig durch die SqueezeCenter Verzeichnisse gestöbert
>
Hallo zusammen,
bin gerade auf diesen Thread gestoßen, da ich das gleiche Problem
habe.. (also dass der 2. Sortierungslauf ewig dauert mit entsprechenden
Einträgen im Scanner log)
Dabei hab ich ein wenig durch die SqueezeCenter Verzeichnisse gestöbert
und bin auf folgendes ErrorLog gestoßen: mys
@rossi: Gratulation, jetzt hast Du unseren Fehler reproduziert. Über das
selbe rede ich die ganze Zeit ;)
mherger;376453 Wrote:
> Dein Kommentar 28 war m.E. ok. Du musst nur sicher stellen, dass
> /share/HDA_DATA/tmp/ existiert und für jederman beschreibbar ist. Mach
> mal "ls -l /share/HDA_DATA
how much about a 'nike dunk' (http://www.afkicks.com) ??every one know??
--
td74wl335
td74wl335's Profile: http://forums.slimdevices.com/member.php?userid=22426
View this thread: http://forums.slimdevices.com/showthread.
@sunnysekot
Bin bis jetzt halt davon ausgegangen, daß es allen gleich wie mir geht
und nur leichte Symptome haben. Das "Raus-Rein-Spiel halt :-).
@all
Gestern neue Version des Fehlers!
Da 7.3.2 bei mir keine FLAC mit Cue-Sheets mehr abspielt, musste ich
die weiter oben beschriebenen 40 FLAC/CUE
Dein Kommentar 28 war m.E. ok. Du musst nur sicher stellen, dass
/share/HDA_DATA/tmp/ existiert und für jederman beschreibbar ist. Mach
mal "ls -l /share/HDA_DATA/tmp/" - was gibt das?
--
mherger
Michael
-
http://www.herger.net/s
Auch bei mir besteht das Problem nach wie vor und ein raus und rein in
die Seite zeigt beharrlich die fortgesetzte Datenbankreinigung.
Also: Wie bringt man MySQL bei, dass es etwas größeres für die
tmp-Files hernimmt?
--
Sunnysekot
---
Oh, sorry!
Bis jetzt dachte ich immer, daß dem bei jedem hier so wie mir ginge und
die Aufregung nicht ganz verstanden.
Gruß,
Rainer
--
rossi
CD > Ripstation Micro > QNAP209(2*1TB) > SC7.3.1 > Allnet Powerline
Ethernet > SB Duet/Linn Numerik _or_ Linn Ikemi _or_ Leak Troughline II
> Triodeso
rossi;375410 Wrote:
> Hallo
> Die Funktion ist ja auch voll da, und einmal raus und wieder rein in
> die Seite, um optisch den Vorgang abzuschließen sollte ja machbar
> sein.
>
Also das behebt das Problem bei mir definitiv nicht... Denke nicht dass
es ein reines Anzeigeproblem ist.
--
Uwi
--
Hallo
Da wir wissen, handelt es sich ja nur um ein Anzeigeproblem, solange
man die "Durchsuchen"-Seite nicht verlässt, drum Respekt an der
Beharrlichkeit von Spheros. ;-)
Die Funktion ist ja auch voll da, und einmal raus und wieder rein in
die Seite, um optisch den Vorgang abzuschließen sollte j
Habe jetzt nochmal deinstalliert und dann auf 7.3.2 geupgraded und der
Fehler besteht immer noch. Hat denn niemand eine Idee?
Hier das Logfile:
0029:
0028:frame 4: main::main (/volume1/SqueezeCenter/scanner.pl line
363)
0027:frame 3: (eval) (/volume1/SqueezeCenter/scanner.pl line 235)
0
Hallo zusammen,
das kann ich leider auch nur bestätigen. Auf meinem Qnap bereinigt er
auch schon seit einer Woche die Datenbank im zweiten Durchgang.
Eine komplette Neuinstallation habe ich auch schon hinter mir, hat aber
nichts gebracht.
Trotzdem Fröhliche Weihnachten an alle :-)
--
Spheros
Hallo
Habe mit Squeezecenter 3.1 genau das gleiche Problem. Ich lasse
Squeezecenter 3.1 auf einer Synology DS107+ laufen und verwende dazu
die neueste Version von SSODS.
Habe schon alles deinstalliert und neu installiert. Hilft nix. Der 2.
Durchgang der Datenbankbereinigung läuft unendlich... Ab
> Aber was passiert?
> tmpfs bleibt auf /tmp. Ich kann es nicht umbiegen!
Das kannst du auch nicht. Was besagte Änderung bewirkt, ist dass MySQL ein
anderes Verzeichnis verwendet. Funktioniert denn SC nun für dich?
Michael
___
slimserver-de mailing li
Also, ich habs probiert:
in der my.cnf (gefunden in /etc)
habe ich unter
[mysqld]
den Eintrag
tmpdir = /share/HDA_DATA/tmp/
gesetzt. (vorher war er
# tmpdir= /tmp/ )
Aber was passiert?
tmpfs bleibt auf /tmp. Ich kann es nicht umbiegen!
(Auch nach SC neu
> Gibts noch andere Ideen, wie ich die Datei umlegen / vergrößern kann?
> Das Webinterface des QNAP bietet scheinbar keinen Zugriff den
> SQL-Server, den SC benutzt (Dienst Web-MySQL ist ja nicht mal
> aktiviert).
Hier geht es nicht darum, eine Datei zu vergrössern, sondern MySQL zu
sagen, wo es
> Gibts noch andere Ideen, wie ich die Datei umlegen / vergrößern kann?
> Das Webinterface des QNAP bietet scheinbar keinen Zugriff den
> SQL-Server, den SC benutzt (Dienst Web-MySQL ist ja nicht mal
> aktiviert).
Hier geht es nicht darum, eine Datei zu vergrössern, sondern MySQL zu sagen, wo
es
Hallo,
da mir das ja keine Ruhe ließ, habe ich es probiert, nachdem jemand auf
dem qnap-Forum schrieb, wie es gehen könnte.
Habe also in der my.cnf
tmpdir auf /share/MD0_DATA/tmp
gesetzt.
Wirkung?
Keine (auch nicht nach Neustart).
df -h bringt das selbe Ergebnis wie vorher:
tmpfs 16.0M 504.0k
mherger;367802 Wrote:
> > Scheint aber nicht an einer Firmware zu liegen, wahrscheinlich
> wirklich
> > an der DB-Größe.
>
> Kannst du bestätigen, dass /tmp standardmässig auf einer 16MB grossen
> (kleinen!) Partition ist ("df -h")? Ich vermute, dass QNAP bzw. MySQL
> auf QNAP irgendwann stolper
Kleine Meldung von mir, da ich die Meldung ja angestoßen hatte:
Ich hab nix gefunden, wie ich tmp auf die HD legen könnte(Leider bietet
das Webinterface von MySQUL nichts dazu an), auch erscheint mir das als
unwissendem NAS-User ein bischen riskant da an irgendwelchen
config-Dateien rumzufummeln,
> Wird die tmp auf 16MB begrenzt unangetastet von SC/SSOTS benutzt, oder
> beim Instalieren so eingerichtet? Wenn ja, dann müsste man flipflip
> informieren!?
Ich weiss nicht, ob er da viel machen kann. Allenfalls dafür sorgen, dass MySQL
einen anderen Ordner verwendet.
--
Michael
Hallo zusammen
2*Michel und 1*Michael, witzig! :-)
Ok, ich verstehe die Problematik mit dem unterschiedlichen generierten
Pfad PC vs. NAS. Wobei man einem solchen fiktiven Programm sicher auch
beibringen könnte, definierte Pfade beginnend mit dem Musikverzeichnis
der NAS anzulegen und dann von d
> "Kannst du das Problem denn auf deinem PC reproduzieren?"
> Meinst Du damit, ob ich eine klar definierte Vorgehensweise an meinem
> Rechner habe, um das Problemchen zu umgehen (ja, geht _immer_, habe ich
> gestern beschrieben)? Oder meinst Du, ob ich das ganze schon mal auf dem
> PC, statt dem NA
> "Kannst du das Problem denn auf deinem PC reproduzieren?"
> Meinst Du damit, ob ich eine klar definierte Vorgehensweise an meinem
> Rechner habe, um das Problemchen zu umgehen (ja, geht _immer_, habe ich
> gestern beschrieben)? Oder meinst Du, ob ich das ganze schon mal auf dem
> PC, statt dem NA
rossi;368135 Wrote:
> Hallo Michael
>
> ... Letzteres würde bedeuten SC auf dem PC installieren und 15000
> Dateien auf die dafür zu kleine (80GB) Festplatte zu kopieren und
> probieren, ob´s läuft. :-(
>
>
Kannst im SC ja auch das Musikverzeichnis auf Deiner NAS angeben...
GRuß
Michel
--
i
Hallo Michael
Da war ich etwas harsch, aber irgendwann platzt einem halt der Kragen.
Mir ist schon klar, dass SC nicht dafür geschrieben ist, um auf einer
NAS zu laufen, auch wenn das in meinen Augen die einzig vernünftige
Lösung ist. Drum bin ich auch geduldiger, wie ich mit einem
Stand-alone-Ge
> Mal ehrlich: Ich habe eigentlich gar nicht vor herauszufinden, was ein
> Putty ist und was das mit dem "df-h" auf sich hat. Ich habe schon zu
> viel Zeit vor dem Rechner für die Sache verblödelt.
Ok, das verstehe ich. Aber wir sehen uns hier einem Problem ausgesetzt, das wir
nicht beheben könne
Hallo Michael
Tut mir leid da kann ich leider nicht weiter helfen.
Mal ehrlich: Ich habe eigentlich gar nicht vor herauszufinden, was ein
Putty ist und was das mit dem "df-h" auf sich hat. Ich habe schon zu
viel Zeit vor dem Rechner für die Sache verblödelt.
Ein einfacher Trick wie z.B. eine Ei
> Scheint aber nicht an einer Firmware zu liegen, wahrscheinlich wirklich
> an der DB-Größe.
Kannst du bestätigen, dass /tmp standardmässig auf einer 16MB grossen
(kleinen!) Partition ist ("df -h")? Ich vermute, dass QNAP bzw. MySQL auf QNAP
irgendwann stolpert, weil ihm der temporäre Speicherpl
Hallo zusammen,
Dieses Problem kenne ich auch schon länger an meiner QNAP209.
Scheint aber nicht an einer Firmware zu liegen, wahrscheinlich wirklich
an der DB-Größe. Beim Rippen meiner Sammlung ist es dann irgendwann
aufgetreten. Bei mir ist die 2. Datenbankbereinigung allerdings
jedesmal so na
> also, ich kenn mich ja mit linux und pearl nicht aus, hab das aber mal
> so interpretiert, dass ich Putty starten und dieses Kommando eingeben
> soll:
Sehr gut :-). Hat zwar nichts mit Perl zu tun, aber das wollte ich tatsächlich.
Tut mir Leid, dass ich nicht so klar war.
> tmpfs
also, ich kenn mich ja mit linux und pearl nicht aus, hab das aber mal
so interpretiert, dass ich Putty starten und dieses Kommando eingeben
soll:
Hier das Ergebnis:
[~] # df -h
FilesystemSize Used Available Use% Mounted on
/dev/ram0 9.7M 7.0M 2.7M
> Es gibt ein tmp Verzeichnis auf root.
> Ist das gemeint?
Ja. Was sagt denn "df -h"?
--
Michael
___
slimserver-de mailing list
slimserver-de@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/slimserver-de
also auf meiner ts-109 habe ich meines Wissens nur eine einzige
Partition.
Platz ist da ohne Ende.
Es gibt ein tmp Verzeichnis auf root.
Ist das gemeint?
--
Sunnysekot
Sunnysekot's Profile: http://forums.slimdevices.com/me
> Hat jemand eine Idee?
auf welcher Partition liegt /tmp? Steht da ev. nur wenig Speicherplatz zur
Verfügung?
--
Michael
___
slimserver-de mailing list
slimserver-de@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/slimserver-de
Hallo?
Hat jemand eine Idee?
--
Sunnysekot
Sunnysekot's Profile: http://forums.slimdevices.com/member.php?userid=20990
View this thread: http://forums.slimdevices.com/showthread.php?t=54725
___
Hallo Michael,
hab inzwischen SC 7.3 drauf.
Also, ich habe es getestet: den Cache-Ordner gelöscht.
Nachdem die neue Datenbank da war, wieder das selbe Problem:
Durchsuche Musik-Verzeichnis (12 von 12) Beendet 00:04:32
Suche Wiedergabelisten (3 von 3) Beendet 00:01:10
Gruppiere "Di
Danke fürs Draufschauen!
Hmm, das werde ich probieren,
aber erst gegen Ende der Woche, da habe ich hoffentlich wieder ein
bißchen Zeit!
--
Sunnysekot
Sunnysekot's Profile: http://forums.slimdevices.com/member.php?userid=2
> tracks.album': DBD::mysql::st execute failed: Incorrect key file for
> table '/tmp/#sql_11fe_1.MYI'; try to repair it at
> /share/HDA_DATA/SqueezeCenter/CPAN/DBIx/Class/Storage/DBI.pm line 771.
Ich würde mal behaupten, deine DB ist im Eimer. Kannst du mal SC stoppen
und seinen Cache Ordner lös
Hallo nochmal.
Nach 3 Stunden Reinigung war der Durchsuchen Button dann tatsächlich
weg und so bleibt es.
Trotzdem reinigt er im 2. Durchgang ewig weiter, ohne dass er einen
einzigen Punkt im Balken weiterkommt (alle Punkte hellgrau).
Das sieht dann heute morgen so aus:
-
Hallo nochmal,
Hier ein Zwischenbericht:
Hab den Scan nochmal gestartet.
Scheint wieder hängenzubleiben, aber der Button ist wieder da.
Hier der momentane Output der Status-Seite:
Durchsuche Musik-Verzeichnis (0 von ) Beendet 00:06:21
Suche Wiedergabelisten (3 von 3) Beendet 00:
Ja, MHerger, ich dachte auch, dass der Button da sein müsste, hab ihn ja
früher gesehen. Bei der 2. Datenbankbereinigung fehlt er aber
scheinbar?
Ich habe den Rescan gestern abgebrochen, indem ich einen neuen
eingeleitet habe (Datenbank löschen und neu aufbauen). Das geht ja und
da ist er dann auc
> Leider kann ich den ReScan dann auch nicht mehr stoppen, weil es dafür
> keinen Button gibt.
Den sollte es allerdings geben in Einstellungen/Status.
Könntest du mal die letzten paar (hundert) Zeilen von scanner.log (ebenfalls in
Einstellungen/Status) senden?
--
Michael
_
Hallo,
ich habe folgendes Problem, konnte aber keinen Foren-Beitrag dazu
finden:
Wenn ich die Datenbank NEU einlesen lasse (alte löschen), geht es
wunderbar.
Wenn ich aber einen ReScan anstosse, der nur nach neuen oder
veränderten Stücken suchen soll, so bekomme ich einen ReScan ohne
Ende.
Was p
72 matches
Mail list logo
