MP3-Player zeigt nicht alle Stücke an

[mabrusto]

sorry - so klappts besser

https://tuxbox-cvs.sourceforge.net/foru ... hp?t=27909

[Zwen]

So , wieder mal ein Happy End ;-)
Mit der neuesten CIFS-Version, die ich heute eingebaut habe, sollte (zumindest laut Changelog) das Problem der fehlenden Dirs/Files behoben sein. Ausserdem funktioniert jetzt auch das Schreiben (Direct Streaming) auf CIFS-Volumes...

Zwen

[mash4077]

Ausserdem funktioniert jetzt auch das Schreiben (Direct Streaming) auf CIFS-Volumes... Zwen

Mit sowas macht man keine Scherze Ist das wirklich war!?

Gruß
mash

[mogway]

Da fällt mir nur eins zu ein:

!!! D A N K E !!!

Gruss
mogway

[JtG-Riker]

Naja, es geht warscheinlich allerdings nur auf AVIA 600er Boxen, habe den Patch schon vor ca einer Woche getestet, bei 500er Boxen gibts einen Kernel-Oops.

Zumindest falls es sich nicht geändert hat, ich hab das mit Npq debugged und ich weis nicht ob Sat_Man das weitergemeldet hat an den CIFS Diff...

Riker

[petgun]

...Ausserdem funktioniert jetzt auch das Schreiben (Direct Streaming) auf CIFS-Volumes...

boah....vielen Dank im Namen aller Windoofis !

DANKEDANKE

Nach erhoehen von rsize und wsize auf 16384 kommt es auch nicht mehr zu Aufnahmeabruechen unter CIFS. BTW blinkt die HDD-Led waehrend einer Aufnahme auf meiner Kiste jetzt mit ca. 1Hz immer nur sehr kurz auf...im Gegensatz zu dem Funkfeuer bei Aufnahmen unter NFS

Vielen Dank!

cu,
peter

[Treito]

BTW blinkt die HDD-Led waehrend einer Aufnahme auf meiner Kiste jetzt mit ca. 1Hz immer nur sehr kurz auf...im Gegensatz zu dem Funkfeuer bei Aufnahmen unter NFS

Das muss dann aber an Deinem Windoof-Server liegen, mit nem originalen Linux-Server, hast Du auch kein Funkfeuer, naja ich zumindest nicht

[petgun]

BTW blinkt die HDD-Led waehrend einer Aufnahme auf meiner Kiste jetzt mit ca. 1Hz immer nur sehr kurz auf...im Gegensatz zu dem Funkfeuer bei Aufnahmen unter NFS

Das muss dann aber an Deinem Windoof-Server liegen, mit nem originalen Linux-Server, hast Du auch kein Funkfeuer, naja ich zumindest nicht

..kann sein. Server ist/war SFU von Microsoft.
Jetzt unter CIFS kam es auch mit 16384 fuer wsize und rsize zu einem Abbruch wenn die Datenrate ueber 7Mbit/sek ansteigt. Bin jetzt auf 32768 und teste weiter.

cu,
peter

[Buster01]

@petgun:

welches image ist den so aktuell das cifs jetzt schon drin ist?

[petgun]

hi,
alle Versuche mit den rsize/wsize Groessen bringen nicht wirklich was. Sobald die Datenrate >7000 kbit/sek ansteigt oder laenger auf hohem Niveau >6000 kbit/sek ist, gibt's einen Abbruch (Daten koennen nicht schnell genug geschrieben werden) mit der immer gleichen Meldung im log:

Code: Alles auswählen

.
PANIC: not enough space in ringbuffer, available 55471, needed 80641
.

..bringt das vielleicht was den Buffer auf die angeforderten 80641 Bytes zu vergroessern ?

cu,
peter

[thegoodguy]

Die Gesamtgroesse des Buffers bei TS -Streaming ist derzeit 188*362*20=1361120 Bytes.
available ist die derzeit verfuegbare restgroesse (i.e. im buffer befinden sich 1361120-55471=1305649 Bytes die warten endlich geschrieben zu werden).
Haette die DBox mehr RAM koennte man den Buffer sicher deutlich vergroessern, aber so bezweifle ich das ein paar Bytes mehr das Problem loesen koennen (wahrscheinlich ist der overhead bei cifs zu gross).

@petgun: probier doch mal dir das stream2file.cpp ohne fdatasync zu compilieren und dann use_o_sync auf aus und per nfs streamen. blinkt dann die festplatten led auch so haeufig? Wobei es durchaus sein kann, das es positiv ist, wenn die led so schnell blinkt (dann werden die daten kontinuierlich geschrieben und nicht ruckweise (wer weiss ob in dem ruck dann noch daten vom netzwerk empfangen werden).

[Buster01]

also auf meiner nokia 2i avia 500 funktioniert das ganze, mit dem dietmarw snapshot von heute früh, nicht.

Code: Alles auswählen

Record channel_id: 20085000a epg: 20085000ae7ff, apids  mode 1                                                              
PES, queue 0 normal.                    
[camd] starting onid 0001 sid 000a                                  
Oops: kernel access of bad area, sig: 11                                        
NIP: C3BB3128 XER: 20000000 LR: C3BB309C SP: C1A09D60 REGS: c1a09cb0 TRAP: 0300                                                                               
   Not tainted              
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11                                               
DAR: 8776F444, DSISR: 000003C9                              
TASK = c1a08000[123] 'neutrino' Last syscall: 5                                               
last math 00000000 last altivec 00000000                                        
GPR00: 00000002 C1A09D60 C1A08000 C0000034 C1A09D68 C1A09D6A C13B0046 C3BB7C54                                                                              
GPR08: 00000002 8776F440 C3BB7A1C 00000002 24248042 100E4D14 7FFFF830 7FFFFAC0                                                                              
GPR16: 7FFFFB60 7FFFFBB0 7FFFFC00 7FFFFB10 00009032 01A09F40 00000000 C1A09DE0                                                                              
GPR24: 00000003 C1975610 C13B0020 00000000 00000000 C3BC0000 FFFFFFFB C13B0020                                                                              
Call backtrace:               
C1975610 C3BB493C C3BA0BE4 C3BAFF18 C3BAAD58 C003D448 C003D980                                                              
C002F750 C002FB24 C000257C 0FA58790 1009A23C 1009593C 100939FC                                                              
1001F778 1001E2E0 1001DE54 1001D68C 0F919194 00000000                                                     
PCR discontinuity: PCR: 0x032CD51DB, OLDPCR: 0x032CC27D0, Diff: 76299                                                                     
Segmentation fault 

und die dbox schaltet sich aus.

[petgun]

Hi,
danke fuer die Erklaerungen! Ich hoffe hier regt sich keiner ueber Off Topic auf ;-)

Die Gesamtgroesse des Buffers bei TS -Streaming ist derzeit 188*362*20=1361120 Bytes.
available ist die derzeit verfuegbare restgroesse (i.e. im buffer befinden sich 1361120-55471=1305649 Bytes die warten endlich geschrieben zu werden).
Haette die DBox mehr RAM koennte man den Buffer sicher deutlich vergroessern, aber so bezweifle ich das ein paar Bytes mehr das Problem loesen koennen (wahrscheinlich ist der overhead bei cifs zu gross).

glaube ich eigentlich nicht das der overhead zu gross ist...mir kommt es so vor dass schreiben/lesen unter NFS einfach nur eine hoehere Prioritat als CIFS und die andern laufenden Prozesse hat und dadurch sein Ding ohne Ruecksicht auf Verluste durchziehen kann. Koennt ihr daran nicht mal schrauben/anschauen ?
Aber auch so wie es jetzt ist, werden sicher alle Windoofis die das mit dem NFS-Server nicht gebacken bekommen begeistert sein.

..probier doch mal dir das stream2file.cpp ohne fdatasync zu compilieren und dann use_o_sync auf aus und per nfs streamen. blinkt dann die festplatten led auch so haeufig?

...wuerde ich sehr gerne testen...wenn ich compilieren koennte

Wobei es durchaus sein kann, das es positiv ist, wenn die led so schnell blinkt (dann werden die daten kontinuierlich geschrieben und nicht ruckweise (wer weiss ob in dem ruck dann noch daten vom netzwerk empfangen werden)

kann sein...die hohe Blinkfrequenz unter NFS stoert auch nicht wirklich und hat imo keinen negativen Einfluss auf die Leistung..und die Festplatte muss das abkoennen. Das es unter CIFS seltener blinkt haengt vielleicht mit den Buffergroessen zu tun die Windows mit CIFS/NFS(SFU) verwendet. BTW blinkt die HDD-Led so gut wie gar nicht, wenn ich ein TS-File mit NFS ueber den Movieplayer abspiele..

Danke fuer euer Engagament,
peter

PS:Gibt's eine Erklaerung warum CIFS schreiben mit avia 500er nicht klappt ?

[JtG-Riker]

@Petegun

Na ist wohl noch ein Bug drin, ich habs ja schon geschrieben das wir den das Diff schon getestet haben, eben deswegen wurde es nicht eingecheckt.

Na wird schon noch gefixt werden.

Riker

[petgun]

@Petegun

Na ist wohl noch ein Bug drin, ich habs ja schon geschrieben das wir den das Diff schon getestet haben, eben deswegen wurde es nicht eingecheckt.

Na wird schon noch gefixt werden.

jau, das glaube ich auch ganz sicher...viel kann das imo nicht mehr sein.

Vielleicht noch ein Hinweis: Obwohl die Aufnahme mit den oben erwaehnten Unterbrechungen bei zu hohen Datenraten funktioniert, ergibt ein 'cat /proc/kcore > /mnt/cifs-writable-dir/file' auf der Konsole folgende Fehlermeldungen:

Code: Alles auswählen

 __alloc_pages: 0-order allocation failed (gfp=0x20/0)
eth0: Memory squeeze, dropping packet.
.
CIFS VFS: Can not get memory for SMB response
.
CIFS VFS: No response buffer
.

die sich immer wiederholen, bis nach sehr langer Zeit (in der die Box haengt) das File (60MB) geschrieben worden ist.
Und noch was: Mit ftp auf die Box, laesst sich auf ein gemountetes CIFS-Share einwandfrei Lesen und Schreiben...was mich vermuten laesst das der CIFS-Code in Ordnung sein muesste...oder ?

Ich hoffe Ihr bleibt dran und bekommt das noch in den Griff.

vielen Dank,
peter

[essu]

also auf meiner nokia 2i avia 500 funktioniert das ganze, mit dem dietmarw snapshot von heute früh, nicht.
[...]
und die dbox schaltet sich aus.

Die Frage ist, ob das wirklich ein recording-Problem ist, meine Nokia500 steigt schon beim mounten aus (CVS-Stand 11.07.04 10:00)

@MOD:
Man könnte den thread vllt teilen

[Buster01]

mounten klappt wunderbar, nur wenn die dateien angelegt werden sollen schaltet sic hdie box ab. die xml-datei wird meißt mit einer größe von 0 bytes erstellt, danach geht nichts mehr.

[gooofi]

mounten klappt wunderbar, nur wenn die dateien angelegt werden sollen schaltet sic hdie box ab. die xml-datei wird meißt mit einer größe von 0 bytes erstellt, danach geht nichts mehr.

das habe ich hier auch so

nokia d-box ii
2x intel
kabel
yadi 1816