WL-HDD

[tuxianer]

So vorhins nochmals ARD probiert. Es bricht immer ab. Aber warum ging es dann heute Nacht?

[merkwuerden]

Tja ich hab keine Idee mehr, zumal ich die Probleme absolut nicht nachvollziehen kann. Hab übers Wochenende (da eh nicht zu hause) die Box einfach mal auf ARD auf die WL-HDD aufnehmen lassen, Abbruch nach 11 Stunden, aber auch nur weil die Platte voll war.

Also völlig ohne Probleme.

 

Hab da jetzt echt auch keinen Plan mehr, was da bei Dir das Problem verursachen könnte.

[tuxianer]

Ich weis auch nicht mehr weiter. Es kann eig. nur entweder an der WL-HDD liegen oder an der Dbox. Aber Dbox würde ich eher mal ausschließen, da ich ja mal ein anders Image eingespielt habe und nix groß verändert habe. Aber die Werte sind ja gut. Das ist es ja, was mich verwundert. Das Ganze kann eigentlich nur eine Einstellungssache seinen. Oder halt ein Hardwaredefekt, was ich aber für sehr unwahrscheinlich halte.

Hier mal die Auslastung während der Aufnahme. Man kann schön sehen, dass der Ram vollläuft.

 

 

Und hier nochmal nen Log:

[zapit] tuned frequency does not match request. difference: 515
[zapit] tuned frequency does not match request. difference: 859
18:43:29.922 eit_set_update_filter, servicekey = 0x44d00016dca, current version 13
kill: you need to specify whom to kill
RECDIR=/mnt/filme - HDD aufwachen!
Record channel_id: 44d00016dca epg: 44d00016dca4918, apids 0x0 mode 1
re-starting /bin/sectionsd
[sectionsd] starting '/bin/sectionsd'
$Id: sectionsd.cpp,v 1.306 2009/09/14 13:33:28 seife Exp $
[sectionsd] getting configuration from environment, starting paused
GETENVI(auto_scanning) = 0
GETENVL(secondsToCache) = 86400
GETENVL(oldEventsAre) = 7200
GETENVL(secondsExtendedTextCache) = 43200
GETENVI(max_events) = 1500
GETENVI(ntprefresh) = 30
GETENVI(ntpenable) = 0
GETENVS(ntp_system_cmd) = /sbin/rdate -s time.fu-berlin.de
GETENVS(epg_dir) = 
GETENVB(update_eit) = 1
GETENVB(bTimeCorrect) = 0
GETENVI(debug) = 0
[sectionsd] Caching max 1500 events
[sectionsd] Caching 1 days
[sectionsd] Caching 12 hours Extended Text
[sectionsd] Events are old 120min after their end time
/var/tuxbox/config/zapit/epgfilter.xml: No such file or directory
/var/tuxbox/config/zapit/dvbtimefilter.xml: No such file or directory
/var/tuxbox/config/mybouquets.xml: No such file or directory
no response from sectionsd
no response from sectionsd
no response from sectionsd
[stream2file]: ringbuffersize 4194304
[stream2file] allocated ringbuffer size: 4194303
[stream2file] filename: '/mnt/filme/Das_Erste_Marienhof_2009-11-23_184339.001.ts'
           myfilename: '/mnt/filme/Das_Erste_Marienhof_2009-11-23_184339'
no response from sectionsd
[stream2file]: error in write: Input/output error
[stream2file]: pthreads exit code: -3, dir: '/mnt/filme', filename: 'Das_Erste_Marienhof_2009-11-23_184339' myfilename: '/mnt/filme'
kill: you need to specify whom to kill
RECDIR=/mnt/filme - HDD aufwachen!
Record channel_id: 44d00016dca epg: 0, apids 0x0 mode 1
re-starting /bin/sectionsd
[sectionsd] starting '/bin/sectionsd'
$Id: sectionsd.cpp,v 1.306 2009/09/14 13:33:28 seife Exp $
[sectionsd] getting configuration from environment, starting paused
GETENVI(auto_scanning) = 0
GETENVL(secondsToCache) = 86400
GETENVL(oldEventsAre) = 7200
GETENVL(secondsExtendedTextCache) = 43200
GETENVI(max_events) = 1500
GETENVI(ntprefresh) = 30
GETENVI(ntpenable) = 0
GETENVS(ntp_system_cmd) = /sbin/rdate -s time.fu-berlin.de
GETENVS(epg_dir) = 
GETENVB(update_eit) = 1
GETENVB(bTimeCorrect) = 0
GETENVI(debug) = 0
[sectionsd] Caching max 1500 events
[sectionsd] Caching 1 days
[sectionsd] Caching 12 hours Extended Text
[sectionsd] Events are old 120min after their end time
/var/tuxbox/config/zapit/epgfilter.xml: No such file or directory
/var/tuxbox/config/zapit/dvbtimefilter.xml: No such file or directory
/var/tuxbox/config/mybouquets.xml: No such file or directory
no response from sectionsd
no response from sectionsd
[stream2file] INFO: /mnt/filme/Das_Erste_Marienhof_2009-11-23_184339.xml already exists, not overwriting
[stream2file]: ringbuffersize 4194304
[stream2file] allocated ringbuffer size: 4194303
[stream2file] filename: '/mnt/filme/Das_Erste_Marienhof_2009-11-23_184339.001.ts'
           myfilename: '/mnt/filme/Das_Erste_Marienhof_2009-11-23_184339'
[stream2file] /mnt/filme/Das_Erste_Marienhof_2009-11-23_184339.001.ts exists, retrying...
[stream2file] filename: '/mnt/filme/Das_Erste_Marienhof_2009-11-23_184339.002.ts'
           myfilename: '/mnt/filme/Das_Erste_Marienhof_2009-11-23_184339'
changeDMX: for 0x4e not ignored! even though real_pauseCounter> 0 (1)
changeDMX: for 0x0 not ignored! even though real_pauseCounter> 0 (1)
changeDMX: for 0x60 not ignored! even though real_pauseCounter> 0 (1)

[tuxianer]

Was bedeuten beim Top eigentlich die Werte?

 

Free, Buffers, Cached. Wo sehe ich, wie stark der Ringpuffer gefüllt ist?

[merkwuerden]

Was bedeuten beim Top eigentlich die Werte?

 

Free, Buffers, Cached

Free: momentan wirklich freier (ungenutzter) RAM

Buffers: interne Puffer für Prozesse und Daten, keine Ahnung, was da alles wirklich drin steckt

Cached: zwischengespeicherte Daten, der Ringpuffer dürfte (neben anderem) in Cached mit zu finden sein.

 

Wo sehe ich, wie stark der Ringpuffer gefüllt ist?

Den Füllstand des Ringpuffers kannst Du direkt nirgends ablesen, zumindest ist mir keine Möglichkeit dazu bekannt. Du siehst das höchstens indirekt anhand der Differenz des von Neutrino belegten Speichers vor und während des Aufnahmeprozesses und den Schwankungen der Angaben unter free sowie cached.

 

Was mir anhand Deines Top-Logs auffällt: Deine Box ist schwer beschäftigt mit irgendwelchen Prozessen. Könnte gut sein, dass die Box mit anderen Dingen so zu tun hat, dass sie für den (wichtigeren) Aufnahmeprozess ungenügend Zeit hat und diesen aus Mangel freier Prozess-Zeit dann komplett vernachlässigen könnte, was zu Störungen führen dürfte. 87% vom System verwendet, allein 30% CPU von Neutrino verbraten, nur noch knapp 7% freie Prozess-Zeit - ist in meinen Augen erheblich zu viel Beschäftigung der Box insgesamt.

 

Ich habe hier eben mal parallel Sky SciFi beim Streamen, bei meiner Philips sieht das bedeutend gemütlicher aus:

 9:25pm  up 15 days, 22:20,  0 users,  load average: 0.62, 0.43, 0.28
49 processes: 48 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:   4.5% user,  24.9% system,   0.0% nice,  70.6% idle
Mem:     30884K total,    29676K used,     1208K free,     3152K buffers
Swap:        0K total,        0K used,        0K free,     7596K cached

 PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
20200 root      14   0   840  840   680 R    12.1  2.7   0:33 top
20178 root       3 -15  7040 6228  2752 S <   1.2 20.1   0:24 neutrino
20180 root       9   0   584  584   508 S     1.0  1.8   0:05 telnetd
   3 root      19  19     0    0     0 SWN   0.6  0.0  10:18 ksoftirqd_CPU0
1836 root       3 -15  7040 6228  2752 S <   0.5 20.1 196:10 neutrino
20179 root       3 -15  7040 6228  2752 S <   0.5 20.1   0:10 neutrino
 309 root       9   0  1816 1816  1264 S     0.1  5.8   0:50 zapit
1805 root      13   5  4688 4688  1284 S N   0.1 15.1   1:55 sectionsd
20175 root       9   0     0    0     0 SW    0.1  0.0   0:08 rpciod
   1 root       8   0   504  500   480 S     0.0  1.6   0:04 init
   2 root       9   0     0    0     0 SW    0.0  0.0   0:04 keventd
   4 root       9   0     0    0     0 SW    0.0  0.0   0:00 kswapd
   5 root       9   0     0    0     0 SW    0.0  0.0   0:00 bdflush
   6 root       9   0     0    0     0 SW    0.0  0.0   0:00 kupdated
   7 root       9   0     0    0     0 SW    0.0  0.0   0:00 mtdblockd
  14 root      15  10     0    0     0 SWN   0.0  0.0   0:00 jffs2_gcd_mtd3
  70 root       9   0     0    0     0 SW    0.0  0.0  17:58 avia_av_wdt
  74 root       9   0     0    0     0 SW    0.0  0.0   0:00 avia_gt_wdt
 106 root       9   0   612  612   528 S     0.0  1.9   0:00 inetd
 149 root       9   0   568  568   504 S     0.0  1.8   0:00 syslogd
 166 root       9   0     0    0     0 SW    0.0  0.0   0:00 cifsoplockd
 170 root       9   0   688  688   576 S     0.0  2.2   0:03 automount
 179 root       9   0   540  536   468 S     0.0  1.7   0:00 start_neutrino
 180 root       9   0   504  500   480 S     0.0  1.6   0:00 init
 181 root       9   0   504  500   480 S     0.0  1.6   0:00 init
 182 root       9   0   504  500   480 S     0.0  1.6   0:00 init
 183 root       9   0   504  500   480 S     0.0  1.6   0:00 init
 186 root       9   0   504  500   480 S     0.0  1.6   0:00 init
 187 root       9   0   504  500   484 S     0.0  1.6   0:00 init
 212 root       9   0  1212 1212  1040 S     0.0  3.9   0:00 timerd
 219 root       9   0  1212 1212  1040 S     0.0  3.9   0:00 timerd
 220 root       9   0  1212 1212  1040 S     0.0  3.9   0:00 timerd
 232 root       9   0     0    0     0 SW    0.0  0.0   0:00 kdvb-fe-0:0
 307 root       9   0   444  440   384 S     0.0  1.4   0:04 camd2
 315 root       9   0  1816 1816  1264 S     0.0  5.8   0:00 zapit
 316 root       9   0  1816 1816  1264 S     0.0  5.8   0:03 zapit
 442 root       9   0  2168 2168  1588 S     0.0  7.0   0:15 nhttpd
1806 root      13   5  4688 4688  1284 S N   0.0 15.1   0:00 sectionsd
1807 root      12   5  4688 4688  1284 S N   0.0 15.1   2:52 sectionsd
1809 root      13   5  4688 4688  1284 S N   0.0 15.1  31:13 sectionsd
1812 root      13   5  4688 4688  1284 S N   0.0 15.1  17:11 sectionsd
1813 root      13   5  4688 4688  1284 S N   0.0 15.1   0:17 sectionsd
1814 root      13   5  4688 4688  1284 S N   0.0 15.1   0:00 sectionsd
1815 root      13   5  4688 4688  1284 S N   0.0 15.1   0:20 sectionsd
1816 root      13   5  4688 4688  1284 S N   0.0 15.1  13:44 sectionsd
1834 root       3 -15  7040 6228  2752 S <   0.0 20.1   5:39 neutrino
1835 root       3 -15  7040 6228  2752 S <   0.0 20.1   0:00 neutrino
1837 root       3 -15  7040 6228  2752 S <   0.0 20.1   0:00 neutrino
20181 root       9   0   648  648   556 S     0.0  2.0   0:00 sh

Wie Du siehst, ist die Box zu 70% untätig. Das ist übrigens auch bei Aufnahmen von ARD so der Fall.

 

Hast Du zufälligerweise eine Nokia? Ich hab nämlich so einen Kandidaten, der auch ohne Aufnahme und dergleichen massig CPU-Zeit verbrät und teils extrem träge trotz genug freiem RAM reagiert. Hatte da im KW-Image-Bereich hier (klick) deshalb mal angefragt, bisher allerdings keinerlei nutzbringende Antwort erhalten. Ich habe keine Erklärung für dieses Verhalten der Box. Aufnahme hab ich mit der Kiste schon gleich gar nicht erst versucht, das Teil ist so schon träge genug, die Box steht erst mal in der Ecke.

Meine drei Philips und die Sagem tun dagegen ihre Aufgaben einwandfrei - ohne unsinniges Gemehre.

[tuxianer]

Ja. Ich habe eine Nokia. Auf jeden Fall scheint es wirklich so zu sein, dass der Puffer am Anfang voll läuft. Wenn die Aufnahme ein paar Minuten läuft ist es unwahrscheinlich, dass sie abbricht. Unnötige Prozesse kann ich eigentlich nicht haben. Ich hab das Image aufgespielt, und dann alle Plugins gelöscht. Also nach dem reboot habe ich 84% Idle. Bei anderen Sendern ist die Last auch nicht all zu Groß. Aber bei ARD schwankt Idle zwischen 20 und 6 während der Aufnahme.

[tuxianer]

Also vorhins gerade wieder mehrere GB ARD aufgenommen. Das ganze ist echt komisch. Vlt liegt es wirklich an der Nokia Box. Und da die meisten Nokia haben geht es vlt. deswegen auch bei vielen nicht. Du könntest ja mal versuchen mit deiner Nokia ARD zu streamen.

 

Hier nochmal ein paar CPU/Ram Werte:

 

Nach Reboot: 82% Idle 7054k free

RTL Aufnahme: 28,5% Idle 888k free

ARD Aufnahme: 15,3% Idle 648k free

 

Aktuell 2h Uptime und vorher die Aufnahmen:

83% Idle 12948k free

[tuxianer]

Also ich habe es immer noch nciht zum laufen bekommen. Aber ab und zu kam jetzt der Fehler: "Fehler beim Aufnehmen der Datei" oder so ähnlich. Was bedeutet das?

[merkwuerden]

Du könntest ja mal versuchen mit deiner Nokia ARD zu streamen.

Habe ich eben mit allen zur Verfügung stehenden Mitteln der Kunst versucht, Resultat: unmöglich. Selbiges Verhalten wie bei Dir: die Aufnahmen werden total zerstückelt. Es liegt allerdings definitiv nicht an der Netzwerkgeschwindigkeit und auch nicht an der Speicherauslastung, sondern an der Prozesslast der CPU, und zwar nur bei der Nokia!

Philips und Sagem laufen einwandfrei, da gibt es keinerlei Probleme, CPU bei mindest 60% Leerlauf. Bei der Nokia dagegen lediglich bei 3 bis 0% (!!!). Da müssen die Aufnahmen gezwungenermaßen abbrechen, weil die Box den Prozess überhaupt nicht mehr vernünftig bedienen kann.

 

Zur Information: meine Testboxen (Philips/Sagem/Nokia) besitzen identische Images mit identischer Konfiguration, alle drei Avia600.

 

Fakt ist auf jeden Fall, dass die CPU-Last bei Nokia auf Maximum springt, so wie der Aufnahmeprozess beginnt.

 

Ich habe da schwer den sectionsd im Verdacht, weil der permanent für erhebliche CPU-Last sorgt, so wie der Prozess überhaupt im Hintergrund läuft. Ob er dabei Daten sammelt oder (per sectionsdcontrol) schlafen gelegt ist, spielt dabei absolut keine Rolle. Bei der Nokia zwischen 35 und 40% System, User und Nice bei 0%. Bei Philips/Sagem dagegen maximal System 15%, User und Nice ebenfalls 0%. Killt man den sectionsd per telnet (es darf danach die Fernbedienung nicht mehr angefasst werden, weil sonst der sectionsd durch diverse Hintergrundüberwachung sofort wieder aktiv wird!), ist auch die Nokia plötzlich im Leerlauf. Überwacht mit dem Sysinfo-Plugin.

Was da übrigens diese Systemlast von fast 40% bei Nokias erzeugt, ist anhand von Top nicht zu sehen, zusammengezählt ergeben die aktiven Prozesse gerade mal 15% CPU (wie bei Philips/Sagem). Irgendwas passt da absolut nicht zusammen...

 

Warum ich den sectionsd im Verdacht habe? Weil es da in den letzten Monaten im CVS einige spezifische Patches (speziell für ARD und wohl auch einige andere Öffentlich-Rechtliche) gab, die nur bei Nokias ziehen, bei Philips/Sagem dagegen nicht. Vermutlich verursacht dieses Gepatche entsprechend CPU-Last im Hintergrund, so lange der sectionsd läuft.

Und nach dem sectionsd wird automatisch gefragt, sobald z.B. die Infobar angezeigt wird, was ja bei jedem Aufnahmeversuch statt findet. Hat demzufolge auch keinerlei Zweck, den sectionsd vor der Aufnahme zwangszukillen, Neutrino fragt den trotzdem ab, auch wenn per KW-Keep-Alive die Überwachung deaktiviert wird. Und hat deswegen dann wohl keine Zeit mehr, den Aufnahmeprozess vernünftig zu bedienen, weil mit allem möglichen anderen Mist beschäftigt.

 

Stellt man den sectionsd in den Aufnahmeeinstellungen auf "anhalten", funktioniert gleich überhaupt nichts mehr, obwohl das ja eigentlich zur Entlastung der Box beitragen sollte. Aufnahmeversuche brechen augenblicklich ab, keine 4MB, die geschrieben werden (nachdem erst mal rund 3 Sekunden überhaupt kein Byte von der Nokia über das Netzwerk kommt, die Philips beginnt sofort mit Senden).

 

Einstellungen -> Aufnahme -> Sectionsd -> neu starten dagegen bringt zumindest Schein-Erfolg, die Aufnahme startet erst mal. Allerdings etliche Sekunden verspätet wegen des Neustart des sectionsd.

Die Systemlast liegt aber bei über 85%, ich glaube nicht, dass das dauerhaft gut geht - nein, tut es nicht. Abbruch nach 320MB, Ringbuffer übergequollen, konnte angeblich nicht schnell genug geschrieben werden (Spitze bei 8,2Mbit/s), was ich aber bei meinem Netzwerkdurchsatz für ein Gerücht halte, damit sind die derzeit maximal gesendeten 8Mbit/s (laut Netzwerkdurchsatz am Server-PC überwacht) absolut kein Thema, die Philips kann das auch ohne Abbrüche (bis 9,2Mbit/s).

Die Fortsetzung der Aufnahme läuft jetzt seit 1,8GB, Datenspitze war laut PC 8,7Mbit/s.

 

Wenn ich mir das Theater so ansehe, sinken Nokia-dBox2 damit bei mir unter den Nullpunkt, sowas muss man nicht haben...

Philips und Sagem laufen jedenfalls einwandfrei.

 

 

@tuxianer

 

Was Du versuchen könntest: ein reines CVS-Image zu flashen. Gibt es z.B welche bei http://tuxbox2.trale.de/. Achtung: Du benötigst dafür Deine ucodes (aviaxxx.ux, cam-alpha.bin und ucode.bin, für PayTV noch eine andere camd2). Ich vermute mal, dass Du da aber auch keine Aufnahme vernünftig zustande bringen wirst.

Ich selber spare mir dahingehende Tests.

 

Was ich Dir raten könnte (auch wenn's Dir nicht gefallen wird): schmeiße die Nokia über den Jordan und besorge Dir eine Philips. Die sind keinen Deut schlechter als Nokias und machen vor allem kein Affentheater mit fragwürdigen (vermurksten?) EPG-Events (weswegen diverse (Krampf)Patches im sectionsd für Nokias eingebaut wurden). Keine Ahnung, was da die Hardware der Nokias anders macht als die der Philips/Sagems.

 

Ich habe fertig...

[tuxianer]

Also es scheint wirklich am beschriebenen sectionsd zu liegen. Ich habe auch im Internet ein wenig gelesen, das Problem ist wohl schon länger bekannt. Ich habe u.a. das gefunden:

 

http://www.dbox2-tuning.net/forum/viewtopic.php?f=31&t=47971

http://www.dbox2-tuning.net/forum/viewtopic.php?f=31&t=42768

 

Dort wurde auch per script versucht sectionsd kurz nach Aufnahme start zu beenden. Scheinbar auch mit Erfolg. Ich kenne mich mit dem scripten auf der Dbox allerdings nicht gut genug aus, um das alles nachzuvollziehen.

 

Dann würde evtl ein Wechsel auf Enigma etwas bringen, ich habe gelesen, dass das kein sectionsd verwendet, stimmt das?