Linux - Thread

[Thordis V.]

Ich hab einen Sauhaufen mit diesem Klauncher...

 

[Tomatentöter]

*ausbuddel*


So, vielleicht kann mir wer bei meinem Problem helfen, das seit dem Upgrade von Suse 11.2 auf Suse 11.3 auftritt.

Ich habe ein Netzlaufwert als cifs gemountet, kann auch problemlos drauf zugreifen (Konqueror, Dolphin, Konsole). Nur wenn ich mit audacious eine Datei aus diesem Verzeichnis in die Playliste einfügen will bringt er die Fehlermeldung: "lseek failed: Das Argument ist ungültig."

Ich hab keine Idee woran das liegen könnte, vielleicht sonst jemand?

 

[Colamann3798]

Starte audacious bitte mal aus ner Konsole, mit der Option --verbose . Und dann poste noch mal die Fehlerausgabe aus der Konsole.

 

[Tomatentöter]

Das is die Fehlerausgabe:

probe.c:176 [file_find_decoder]: Probing file:///media/HITACHI/Musik/The%20Traceelords%20-%20Daddy%20Cool.mp3.
probe.c:124 [probe_by_scheme]: Probing by scheme.
probe.c:138 [probe_by_extension]: Probing by extension.
probe.c:112 [probe_func_fast]: Guessing MPG123.
VFS: <0xd2ef40> open (mode r) file:///media/HITACHI/Musik/The%20Traceelords%20-%20Daddy%20Cool.mp3
VFS: <0xd2ef40> seek to 0 from end
VFS: <0xd2ef40> tell = 0
VFS: <0xd2ef40> seek to -128 from end
util.c:83 [audgui_simple_message]: lseek failed: Das Argument ist ungültig.
VFS: <0xd2ef40> read 4 elements of size 1 = 0
mpg123 probe error for file:///media/HITACHI/Musik/The%20Traceelords%20-%20Daddy%20Cool.mp3: Message: I am done with this track.
VFS: <0xd2ef40> close

edit:
Zum Vergleich dieselbe Datei von einem lokalen Verzeichnis hinzugefügt:

probe.c:176 [file_find_decoder]: Probing file:///home/user/Musik/The%20Traceelords%20-%20Daddy%20Cool.mp3.
probe.c:124 [probe_by_scheme]: Probing by scheme.
probe.c:138 [probe_by_extension]: Probing by extension.
probe.c:112 [probe_func_fast]: Guessing MPG123.
VFS: <0xc11b20> open (mode r) file:///home/user/Musik/The%20Traceelords%20-%20Daddy%20Cool.mp3
VFS: <0xc11b20> seek to 0 from end
VFS: <0xc11b20> tell = 4005702
VFS: <0xc11b20> seek to -128 from end
VFS: <0xc11b20> tell = 4005574
VFS: <0xc11b20> read 128 elements of size 1 = 128
VFS: <0xc11b20> seek to 0 from beginning
VFS: <0xc11b20> tell = 0
VFS: <0xc11b20> read 4 elements of size 1 = 4
VFS: <0xc11b20> seek to 518 from current
VFS: <0xc11b20> tell = 522
VFS: <0xc11b20> read 4 elements of size 1 = 4
VFS: <0xc11b20> seek to -522 from current
VFS: <0xc11b20> tell = 4
VFS: <0xc11b20> read 518 elements of size 1 = 518
VFS: <0xc11b20> size = 4005702
VFS: <0xc11b20> rewind
VFS: <0xc11b20> seek to 0 from beginning
VFS: (last message repeated 1 times)
VFS: <0xc11b20> read 10 elements of size 1 = 10
VFS: <0xc11b20> size = 4005702
VFS: <0xc11b20> seek to 4005692 from beginning
VFS: <0xc11b20> read 10 elements of size 1 = 10
VFS: <0xc11b20> seek to 0 from beginning
VFS: (last message repeated 1 times)
VFS: <0xc11b20> read 10 elements of size 1 = 10
VFS: <0xc11b20> seek to 0 from beginning
VFS: (last message repeated 1 times)
VFS: <0xc11b20> read 32 elements of size 1 = 32
VFS: <0xc11b20> seek to -32 from end
VFS: <0xc11b20> read 32 elements of size 1 = 32
ape/ape.c:157 [ape_find_header]: No header found.
VFS: <0xc11b20> seek to 0 from beginning
VFS: <0xc11b20> seek to -355 from end
VFS: <0xc11b20> read 4 elements of size 1 = 4
VFS: <0xc11b20> seek to -128 from end
VFS: <0xc11b20> read 3 elements of size 1 = 3
tag_module.c:72 [find_tag_module]: no module found
VFS: <0xc11b20> close

 

[King-of-Darkness]

Das is die Fehlerausgabe:

VFS: <0xd2ef40> open (mode r) file:///media/HITACHI/Musik/The%20Traceelords%20-%20Daddy%20Cool.mp3
VFS: <0xd2ef40> seek to 0 from end
[COLOR="red"]VFS: <0xd2ef40> tell = 0[/COLOR]
VFS: <0xd2ef40> seek to -128 from end
util.c:83 [audgui_simple_message]: lseek failed: Das Argument ist ungültig.

edit:
Zum Vergleich dieselbe Datei von einem lokalen Verzeichnis hinzugefügt:

VFS: <0xc11b20> open (mode r) file:///home/user/Musik/The%20Traceelords%20-%20Daddy%20Cool.mp3
VFS: <0xc11b20> seek to 0 from end
[COLOR="Red"]VFS: <0xc11b20> tell = 4005702[/COLOR]

Das ist ja funny... Rechte hast du aber auf /media/Hitachi, nehme ich mal an. Kannst du mal versuchen, ein lokales Medium dort zu mounten und dann nen Einlesevorgang zu starten? Ich meine, im Prinzip dürfte es keinen Unterschied machen, aber eventuell ist das Proggi mit der Verbindung unzufrieden. Schon mal über SSH probiert? Ansonsten Bugreport, es scheint ja was im Quellcode schief gelaufen zu sein (wahrscheinlich im CIFS-Paket - schau mal nach, ob sich die Version seit dem Update geändert hat).

Ansonsten hab ich eigentlich Ubuntu/Debian, bin aber mit dem CIFS-Geschisse vertraut. Sobald Unix was von Windows will, zickt Redmond teils wie ein kleines Kind...

 

[Tomatentöter]

Ja, das mit dem 0 und einmal nicht 0 is mir auch aufgefallen, nur schlau geworden bin ich daraus bis jetzt noch nicht.

Und an den Zugriffsrechten liegt es nicht, denn auch wenn ich das als root mache tritt genau deselbe Fehler auf. Außerdem hab ich ja sonst auch keine Probleme auf das Laufwerk zuzugreifen. Kaffeine spielt z.B. ohne Probleme davon ab.

 

[King-of-Darkness]

Ja, das mit dem 0 und einmal nicht 0 is mir auch aufgefallen, nur schlau geworden bin ich daraus bis jetzt noch nicht.
...
Kaffeine spielt z.B. ohne Probleme davon ab.

Ich hab auch keine Ahnung, was er da genau zurückgibt - nen Returncode ist es jedenfalls nicht. Sieht nach ner Dateigröße aus.

Warte mal - hast du auf dem Host (Server) Schreibrechte auf die Datei? Rechtemanagement läuft hier nämlich Hostseitig ab (d.h. Audacious als root bringt dir gar nix), und Audacious versucht evl. fehlerhafte ID3-Tags/Header zu schreiben bzw. zu korrigieren. Könnte nämlich sein, dass im Dateiheader die Dateigröße nicht richtig angegeben ist. Wenn du natürlich per Remote die Datei auch löschen/umbenennen kannst (in Konqueror etc), dann liegts am Audacious und du darfst das Entwicklerteam mal kontaktieren und nen Bugreport schreiben. Üblicherweise fixen sie ja die meisten Pakete recht flott...

 

[Tomatentöter]

Ich hab auch keine Ahnung, was er da genau zurückgibt - nen Returncode ist es jedenfalls nicht. Sieht nach ner Dateigröße aus.

Warte mal - hast du auf dem Host (Server) Schreibrechte auf die Datei? Rechtemanagement läuft hier nämlich Hostseitig ab (d.h. Audacious als root bringt dir gar nix), und Audacious versucht evl. fehlerhafte ID3-Tags/Header zu schreiben bzw. zu korrigieren. Könnte nämlich sein, dass im Dateiheader die Dateigröße nicht richtig angegeben ist. Wenn du natürlich per Remote die Datei auch löschen/umbenennen kannst (in Konqueror etc), dann liegts am Audacious und du darfst das Entwicklerteam mal kontaktieren und nen Bugreport schreiben. Üblicherweise fixen sie ja die meisten Pakete recht flott...

Also ich kann z.B. in der Konsole auf dem Server ne Datei erstellen, ändern, löschen, alles ohne Probleme. Dolphin und Konqueror tun selbiges.

Ich frag mich dann nur, warum es dann unter 11.2 noch gelaufen ist und jetzt unter 11.3 nicht mehr

 

[King-of-Darkness]

Also ich kann z.B. in der Konsole auf dem Server ne Datei erstellen, ändern, löschen, alles ohne Probleme. Dolphin und Konqueror tun selbiges.

Ich frag mich dann nur, warum es dann unter 11.2 noch gelaufen ist und jetzt unter 11.3 nicht mehr

Wie gesagt, dann ist nen Bugreport fällig. Haben sie entweder beim CIFS-Paket oder in Audacious ne Änderung durchgeführt, die ein Zugriffsproblem verursacht. Mehr kann ich dir leider nicht sagen, bin kein Entwickler.

 

[Tomatentöter]

So, ich hab grad die Lösung gefunden

Es liegt an der Firmware des Clients. Hab das Laufwerk jetzt nämlich über einen anderen Client eingebunden und jetzt gehts ohne Probleme.

Früherer Client: Irgendwas proprietäres, Befehle der Konsole sind DOS-ähnlich.
Aktueller Client: Unixbasiertes System

Was lernen wir daraus: Anständige Software und keinen proprietären Müll verwenden