Ankündigung: Vorabversion DVB-Treiber 1.1.0

Zitat

Original von sigii
Erst mal ein Hallo an alle,

und nun gleich zum Thema,

habe gerade exakt das gleiche Problem gehabt.
kurz nach Aufnahmebegin macht der VDR einen Restart.

hier mal eine Auszug aus der messages:

Feb 23 20:06:53 htpc vdr[604]: switching to channel 1
Feb 23 20:11:00 htpc vdr[604]: timer 1 (14 2011-2200 'Tatort: Lastrumer Mischung') start
Feb 23 20:11:00 htpc vdr[604]: record /video/Tatort#3A_Lastrumer_Mischung/2004-02-23.20.11.50.50.rec
Feb 23 20:11:31 htpc vdr[604]: timer 1 (14 2011-2200 'Tatort: Lastrumer Mischung') stop
Feb 23 20:11:31 htpc vdr[604]: saved setup to /etc/vdr/setup.conf
Feb 23 20:11:31 htpc vdr[604]: stopping plugin: streamdev
Feb 23 20:11:31 htpc vdr[739]: Streamdev: Server thread stopped
Feb 23 20:11:31 htpc vdr[604]: stopping plugin: calendar
Feb 23 20:11:31 htpc vdr[604]: stopping plugin: osdpip
Feb 23 20:11:31 htpc vdr[604]: stopping plugin: timeline
Feb 23 20:11:31 htpc vdr[604]: exiting
Feb 23 20:11:31 htpc runvdr: restarting VDR

Und hier noch die syslog:

Feb 23 20:06:53 htpc vdr[604]: switching to channel 1
Feb 23 20:11:00 htpc vdr[604]: timer 1 (14 2011-2200 'Tatort: Lastrumer Mischung') start
Feb 23 20:11:00 htpc vdr[604]: Title: 'Tatort: Lastrumer Mischung' Subtitle: 'Spielfilm Deutschland 2002'
Feb 23 20:11:00 htpc vdr[604]: record /video/Tatort#3A_Lastrumer_Mischung/2004-02-23.20.11.50.50.rec
Feb 23 20:11:00 htpc vdr[604]: creating directory /video/Tatort#3A_Lastrumer_Mischung
Feb 23 20:11:00 htpc vdr[604]: creating directory /video/Tatort#3A_Lastrumer_Mischung/2004-02-23.20.11.50.50.rec
Feb 23 20:11:00 htpc vdr[604]: recording to '/video/Tatort#3A_Lastrumer_Mischung/2004-02-23.20.11.50.50.rec/001.vdr'
Feb 23 20:11:00 htpc vdr[796]: recording thread started (pid=796)
Feb 23 20:11:00 htpc vdr[797]: receiver thread started on device 2 (pid=797)
Feb 23 20:11:31 htpc vdr[796]: ERROR: video data stream broken
Feb 23 20:11:31 htpc vdr[796]: initiating emergency exit
Feb 23 20:11:31 htpc vdr[604]: emergency exit requested - shutting down
Feb 23 20:11:31 htpc vdr[796]: recording thread ended (pid=796)
Feb 23 20:11:31 htpc vdr[797]: receiver thread ended on device 2 (pid=797)
Feb 23 20:11:31 htpc vdr[604]: buffer stats: 0 (0%) used
Feb 23 20:11:31 htpc vdr[604]: timer 1 (14 2011-2200 'Tatort: Lastrumer Mischung') stop
Feb 23 20:11:31 htpc vdr[613]: KBD remote control thread ended (pid=613)
Feb 23 20:11:31 htpc vdr[604]: saved setup to /etc/vdr/setup.conf
Feb 23 20:11:31 htpc vdr[604]: =====================
Feb 23 20:11:31 htpc vdr[604]: EPG bugfix statistics
Feb 23 20:11:31 htpc vdr[604]: =====================
Feb 23 20:11:31 htpc vdr[604]: IF SOMEBODY WHO IS IN CHARGE OF THE EPG DATA FOR ONE OF THE LISTED
Feb 23 20:11:31 htpc vdr[604]: CHANNELS READS THIS: PLEASE TAKE A LOOK AT THE FUNCTION cEventInfo::FixEpgBugs()
Feb 23 20:11:31 htpc vdr[604]: IN VDR/eit.c TO LEARN WHAT'S WRONG WITH YOUR DATA, AND FIX IT!
Feb 23 20:11:31 htpc vdr[604]: =====================
Feb 23 20:11:31 htpc vdr[604]: Fix^IHits^IChannels
Feb 23 20:11:31 htpc vdr[604]: 0^I16544^IZDF, SWR BW, Hessen-3, SR3, 3sat, arte, BR3, BR-alpha, MDR, ARD, VIVA, RBB Berlin, RBB Brandenburg, EinsFestival, N3, TW1
Feb 23 20:11:31 htpc vdr[604]: 1^I855^IHessen-3, VIVA, n-tv
Feb 23 20:11:31 htpc vdr[604]: 2^I13373^ISWR BW, Hessen-3, SR3, 3sat, arte, BR3, BR-alpha, MDR, ARD, VIVA, RBB Berlin, RBB Brandenburg, EinsFestival, N3
Feb 23 20:11:31 htpc vdr[604]: 3^I89756^IKabel 1, Pro-7, N24, Sat.1, KiKa
Feb 23 20:11:31 htpc vdr[604]: 4^I549^IBR3, EinsFestival
Feb 23 20:11:31 htpc vdr[604]: 5^I5377^IWDR, BR3
Feb 23 20:11:31 htpc vdr[604]: 6^I99589^IPro-7, N24, Sat.1, 3sat, SWR BW, BR3, Hessen-3, arte, Phoenix, WDR, SR3, BR-alpha, ARD, EinsExtra, MDR, N3, n-tv, VIVA, RTL Tele Letzebuerg, Bloomberg TV Germany, VIVA PLUS, RBB Berlin, EinsFestival, EinsMuXx, RBB Brandenburg, Sky News, TW1, QVC Germany
Feb 23 20:11:31 htpc vdr[604]: =====================
Feb 23 20:11:31 htpc vdr[607]: EIT processing thread ended (pid=607) - master
Feb 23 20:11:31 htpc vdr[608]: tuner thread ended on device 1 (pid=608)
Feb 23 20:11:31 htpc vdr[610]: EIT processing thread ended (pid=610)
Feb 23 20:11:31 htpc vdr[611]: tuner thread ended on device 2 (pid=611)
Feb 23 20:11:31 htpc vdr[604]: stopping plugin: streamdev
Feb 23 20:11:31 htpc vdr[739]: Streamdev: Server thread stopped
Feb 23 20:11:31 htpc vdr[604]: stopping plugin: calendar
Feb 23 20:11:31 htpc vdr[604]: stopping plugin: osdpip
Feb 23 20:11:31 htpc vdr[604]: stopping plugin: timeline
Feb 23 20:11:31 htpc vdr[604]: max. latency time 5 seconds
Feb 23 20:11:31 htpc vdr[604]: exiting
Feb 23 20:11:31 htpc vdr[604]: emergency exit!
Feb 23 20:11:31 htpc runvdr: restarting VDR

Vieleicht von interesse ist, das die 001.vdr 0 Byte groß ist, im Moment nimmt er in die 002.vdr auf. Es scheint so, als ob die 2 Karte bis zum Restart keine Daten aufzeichnent, also nicht richtig initialisiert.

Der VDR wurde per Hand um 18:00 gestartet, bis zum Zeitpunkt des Restarts wurde keine Aufnahme gemacht.

Dazu kommt mir noch in den Sinn, das das OSDPIP manchmal nicht funktioniert, und es erst nach einem Restart des VDR wieder geht. Könnte evtl. das selbe Problem sein.

Der VDR ist ein Hermes mit einer 1.6 und einer Skystar II. Die beiden Karten hängen direkt an einem Quad-LNB.

Gruß
sigii

Alles anzeigen

Hallo,

habe eine ähnliche Systemkonfiguration - Hermes 651, TT1.5 und TT Budget. Die Problme sind bei mir identisch. Erst nach einem Reboot kann ich Aufnahmen machen. Davor sind die Aufnahmen immer nur 0 Byte groß. Ich denke, das dieses Problem nichts mit der Skystar zu tun hat.
Auch ein Entladen der Treiber bringt nichts - reproduzierbar ist das Problem nach einem Reboot verschwunden.

Gruß - Bernd

Hallo,

habe zwar eine andere Konfiguration, aber die Symtome sind die gleichen.
Installation ala Sandmann.
Die Skystar2 rev. 2.6B verabschiedet sich nach einiger Zeit vom System.
Solange sie in Gebrauch ist, sprich Aufnahme oder ich übers Netz streame ist alles OK.
Wenn auf dem System einige Zeit keine Aktivitäten
stattfinden, ist sie weg und nur ein Restart erweck sie wieder zu neuem Leben.

Hi,

ich weiß, dass es nicht viel hilft, aber ich habe gehört, dass einige SiS-Chipsätze (insbesondere 650/651) Probleme mit Skystar2-Karten haben sollen. Dies soll die PCI-Bridge betreffen und würde daher vielleicht die Symptome erklären (Karte tuned, liefert aber keine Daten).

Chipsatz schliesse ich aus! Hatte die gleichen Symtome auf einem
Shuttle AK35GT2 Mainboard (VIA-Chip) unter Suse 9.0!
Habe auf UPT-Error getippt patch eingespielt und Karte beim Start
mit szap getuned. Keine Änderung. Folgende Zeilen aus der Readme
kann ich wegen mangelnder Englischkenntnisse nicht 100% deuten:
Note 2: you must keep ?zap running, or the frontend will go to sleep
(unless you load dvb-core.o with dvb_shutdown_timeout=0)
Heißt das, das die Karte sich schlafen legt wenn sie nicht im direkten Zugriff ist?
Und wenn ja was kann man dagegen tun?
Die Option dvb_shutdown_timeout=0 brachte keine Änderung.

Zitat

Original von armageddon
Chipsatz schliesse ich aus! Hatte die gleichen Symtome auf einem
Shuttle AK35GT2 Mainboard (VIA-Chip) unter Suse 9.0!

War nur so 'ne Idee.

Zitat

Folgende Zeilen aus der Readme
kann ich wegen mangelnder Englischkenntnisse nicht 100% deuten:
Note 2: you must keep ?zap running, or the frontend will go to sleep
(unless you load dvb-core.o with dvb_shutdown_timeout=0)
Heißt das, das die Karte sich schlafen legt wenn sie nicht im direkten Zugriff ist?

Alles anzeigen

Ja, und zwar nach einem Timeout, der in dvb_shutdown_timeout angegeben wird.

Zitat

Und wenn ja was kann man dagegen tun?
Die Option dvb_shutdown_timeout=0 brachte keine Änderung.

Schade, das ist nämlich genau die Methode, um es abzustellen Dann muss das Problem woanders liegen.

psct:

Habe bei den VDR-News hier im Portal entdeckt, dass es einen 1.1.1 Treiber gibt, der ein bug mit dem CI beheben soll:

Changes for linuxtv-dvb-1.1.1:
...
o fixed pointer bug in ring buffer handling which potentially
affected common interface communication
...

Habe nämlich extreme Schwierigkeiten mit dem Alphacrypt an einer TT1.5 (an der 2.1 keine...).
In diesem Thread beschrieben (mit über 1500 Hits!!!!!!):
http://www.vdr-portal.de/board/thread.php?threadid=11715&sid=&threadview=0&hilight=&hilightuser=0&page=2

Nochmal ein Zitat:

"Habe nun noch mal viel probiert und bin zu einer äusserst interessanten Entdeckung gekommen:
-Habe eine TT 1.5 und eine 2.1, die 1.5 ist natürlich wegen RGB das Primäre Device, aber hier stürzt das Alphacam im CI Rev. 1.4 immer ab (liegt zwischen 15min. und 3 Stunden). An der Nexus (2.1) läuft das Modul seit nunmehr 15 Stunden ohne Fehler und das auch immer noch nach "Extrem Zapping" und Start-Stop von einigen Plugins, ein-ausschalten von DD auf Premiere 1 etc.. Habe auch Steckplätze getauscht etc aber ohne Erfolg, es liegt anscheinend an der Treiberunterstützung für die 1.3 Reihe (als diese wird ja auch die 1.6 oder 1.5 erkannt).
Hate mich auch schon gewundert, da ich vorher 2 Nexus hatte und die im Aufbaustadium nie Probleme machten, nun soll das Ding mit RGB und allem ins Wohnzimmer und nu is Asche...
Will das Cam nicht an der zweiten Karte lassen, da ich denn bei einer gestarteten Aufnahme nicht mehr Premiere gucken kann (da immer erst device 2 zur Aufnahme genutzt wird), und es gibt auch nicht annähernd eine befriedigende Lösung das dem VDR beizubringen ob er nun auf Device 1 oder 2 die Aufnahme starten soll.
Werde mal Peter Siering fragen, ob das<evtl. mit dem neuen DVB-Treiber geändert ist."

Vielleicht ne Hoffnungsvolle Antwort??? habe mich noch nicht getraut den 1.1.0 Treiber zu Installieren...

Grüsse
LbgDJ

Hallo!

Da ich ebenfalls noch CAM-Stabilitätsprobleme habe, wäre ich sehr dankbar, wenn dieser neue Bugfix auf "apt-get-Expertenniveau" für den ctvdr verfügbar gemacht würde.

Schöne Dank schon mal,

Grüße
Günther

Hallo,

ich wollte gestern mal die Skystar 2 (Rev.2.6 C) mal ausprobieren, was in einem ziemlichen Desaster geendet ist:

@Peter Siering:
Habe mich dabei an deine Anleitung hier gehalten.

Bereits bei der Installation (mit apt-get install linuxtv-dvb-modules-2.4.23-ctvdr-3) erscheint eine Fehlermeldung bezüglich des bt8xx.o, die ich aber erst einmal dezent ignoriert habe.

Trotzdem ist es mir durch Entladen einiger Module (mittels modconf) und Auskommentieren in der dvb_insmod.sh irgendwann gelungen beide Karten (Nexus DVB-S Rev.1.6 und die SS2) zu erkennen und den VDR zu starten und auch ein Bild angezigt zu bekommen.

Der Hinweis von ajo hier: http://www.vdrportal.de/board/thread.php?threadid=12072&sid=&hilight=skystar2 hat mir auch geholfen...

Beim Versuch eine Sendung aufzunehmen stoppt der vdr jedoch nachziemlich exakt einer Minute (die Aufnahme bis dahin war ok - Timshift etc.). Dann habe ich die modifizierte rundvdr eingespielt und konnte dabei während einer Aufnahme recht kontinuierlich alle 50-60 Sekunden in der messages/syslog einen Neustart des vdr beobachten - ohne einen Hinweis für die Ursache (vielleicht verstehe ich es aber auch nur nicht ). Habe ich den Timer (der noch aktiv war) während der vdr funktioniert hat über das OSD gelöscht, lief er problemlos und ohne Zwangsneustart weiter...

Ergänzend sollte ich vielleicht noch erwähnen, dass während der ersten Versuche noch kein Sat-Kabel an der SS2 angeschlossen war. Das sollte aber nicht der Auslöser für die Neustarts sein oder? Zumindest habe ich es nacher mit Kabel getestet (eigene Leitung vom Multischalter) und bin auch zu keinem anderen Ergebnis gekommen...

Also habe ich erst einmal die alten Treiber wieder installiert und die SS2 ausgebaut.

Habt ihr evt. eine Idee wie ich die Karte doch noch zum Laufen bekomme?

Danke & viele Grüße,
Max

Hallo zusammen,

habe zwar keine Lösung für das Problem (ERROR: video data stream broken), aber kann eine angedeutete Lösung ausschliessen:

Ich fahre schon die DVB Treiber 1.1.1 und habe auch dieses Problem! Damit bekommt man es also nicht weg.

Sonstige Konfiguration:
- Suse 8.2, Kernel 2.4.20
- Haupauge Nexus
- Skystar 2, Rev 2.6C
- DVB Treiber 1.1.1
- VDR 1.2.6

Falls jemand also eine Lösung kennt oder Tipps hat, in welche Richtung ich forschen kann......

Danke,
Ronni

Hi,

wie geht's denn nu weiter?

Alle Aufzeichnungen die ich in der letzten Zeit gemacht habe lassen sich nicht zu DivX umwandeln.
Nach erfolgter Aufnahme habe ich durch den restart des VDR immer eine 0 MB große
VDR-Datei und eine zweite welche die Aufnahme beinhaltet. Aufzeichnung abspielen,
schneiden oder zu SVCD umwandeln sind kein Problem, nur vdr2divx will nicht.
Nach dem schneiden einer Aufnahme steht dann nur noch eine VDR-Datei im neuen Verzeichnis,
anscheinend hat er sich dann die 0 MB große Datei mit einverleibt und deshalb kann vdr2divx
die Source Video Resolution nicht mehr ermitteln.

Im Moment behelfe ich mir damit, das ich vor jeder Aufnahme einen
Fake Timer setze, sprich kurze Aufnahme, VDR restart und dann erst
beginnt die wirkliche Aufnahme.

Hallo!

Habe heut mal den Treiber für die Skystar mit ./insmod.sh debug geladen.

Sieht, glaube ich ganz gut aus, nur dieses claim_adapter?
Müsste hier nicht irgendwo sowas wie PCI: Found IRQ X for device XXX stehen?

Mar 11 15:07:17 linux kernel: Linux video capture interface: v1.00
Mar 11 15:07:17 linux kernel: claim_adapter: card revision 1
Mar 11 15:07:17 linux kernel: claim_adapter: io memory maped at d0bf9000
Mar 11 15:07:17 linux kernel: dma_init_dma: Initializing DMA1 channel
Mar 11 15:07:17 linux kernel: dma_init_dma: first subbuffer address = 0x7fc0000
Mar 11 15:07:17 linux kernel: dma_init_dma: subbuffer size = 0x1d600
Mar 11 15:07:17 linux kernel: dma_init_dma: second subbuffer address = 0x7fdd601
Mar 11 15:07:17 linux kernel: dma_init_dma: counter = 0x7fc0000
Mar 11 15:07:17 linux kernel: dma_init_dma: Initializing DMA2 channel
Mar 11 15:07:17 linux kernel: dma_init_dma: first subbuffer address = 0x860a000
Mar 11 15:07:17 linux kernel: dma_init_dma: subbuffer size = 0x3ac
Mar 11 15:07:17 linux kernel: dma_init_dma: second buffer address = 0x860a3ad
Mar 11 15:07:17 linux kernel: skystar2.c: FlexCopII(rev.130) chip found
Mar 11 15:07:17 linux kernel: skystar2.c: the chip has 6 hardware filters
Mar 11 15:07:17 linux kernel: skystar2.c: useable_hardware_filters set to 6
Mar 11 15:07:17 linux kernel: init_pids: setting filter 0 to 0x1fff
Mar 11 15:07:17 linux kernel: pid_set_hw_pid: id=0 pid=8191
Mar 11 15:07:17 linux kernel: pid_set_hw_pid: id=0 addr=300 l pid=8191
Mar 11 15:07:17 linux kernel: init_pids: setting filter 1 to 0x1fff
Mar 11 15:07:17 linux kernel: pid_set_hw_pid: id=1 pid=8191
Mar 11 15:07:17 linux kernel: pid_set_hw_pid: id=1 addr=300 h pid=8191
Mar 11 15:07:17 linux kernel: init_pids: setting filter 2 to 0x1fff
Mar 11 15:07:17 linux kernel: pid_set_hw_pid: id=2 pid=8191
Mar 11 15:07:17 linux kernel: pid_set_hw_pid: id=2 addr=304 l pid=8191
Mar 11 15:07:17 linux kernel: init_pids: setting filter 3 to 0x1fff
Mar 11 15:07:17 linux kernel: pid_set_hw_pid: id=3 pid=8191
Mar 11 15:07:17 linux kernel: pid_set_hw_pid: id=3 addr=304 h pid=8191
Mar 11 15:07:17 linux kernel: init_pids: setting filter 4 to 0x1fff
Mar 11 15:07:17 linux kernel: pid_set_hw_pid: id=4 pid=8191
Mar 11 15:07:17 linux kernel: pid_set_hw_pid: id=4 addr=308 l pid=8191
Mar 11 15:07:17 linux kernel: init_pids: setting filter 5 to 0x1fff
Mar 11 15:07:17 linux kernel: pid_set_hw_pid: id=5 pid=8191
Mar 11 15:07:17 linux kernel: pid_set_hw_pid: id=5 addr=308 h pid=8191
Mar 11 15:07:17 linux kernel: pid_set_group_pid: pid=0
Mar 11 15:07:17 linux kernel: pid_set_group_mask: pid=1fe0
Mar 11 15:07:17 linux kernel: sram_detect_for_flex2:
Mar 11 15:07:17 linux kernel: sram_detect_for_flex2: tmp2 = 0
Mar 11 15:07:17 linux kernel: sram_detect_for_flex2: tmp3 = 1
Mar 11 15:07:17 linux kernel: sram_test_location: mask = 20000, addr = 18000
Mar 11 15:07:17 linux kernel: sram_test_location: wrote 0xa5, read 0x4f
Mar 11 15:07:17 linux kernel: sram_test_location: mask = 0, addr = 10000
Mar 11 15:07:17 linux kernel: sram_test_location: wrote 0xa5, read 0x4f
Mar 11 15:07:17 linux kernel: sram_test_location: mask = 10000, addr = 0
Mar 11 15:07:17 linux kernel: sram_test_location: wrote 0xa5, read 0xa5
Mar 11 15:07:17 linux kernel: sram_test_location: wrote 0x5a, read 0x5a
Mar 11 15:07:17 linux kernel: sram_detect_for_flex2: sram size = 32K
Mar 11 15:07:17 linux kernel: driver_initialize sram length = 32768, sram type= 10000
Mar 11 15:07:17 linux kernel: DVB: registering new adapter (Technisat SkyStar2 driver).
Mar 11 15:07:17 linux kernel: probe_tuner: try to attach to Technisat SkyStar2 driver
Mar 11 15:07:17 linux kernel: stv0299.c: setup for tuner Samsung TBMU24112IMB
Mar 11 15:07:17 linux kernel: DVB: registering frontend 0:0 (STV0299/TSA5059/SL1935 based)...
Mar 11 15:07:32 linux kernel: free_adapter_object:
Mar 11 15:07:32 linux kernel: close_stream: dma_status=30000000
Mar 11 15:07:32 linux kernel: remove_pid: pid=0

Hallo,
hat sich das Problem des Neustarts bei Aufnahme ueber Skystar, das fussmuff und sigi berichteten, inzwischen

geloest? Ich habe nichts darueber gefunden.

Auch bei mir kommt es regelmaessig kurz nach Beginn der Aufnahme zu einem Neustart. Das ist nicht tragisch, da

danach die Aufnahme ordentlich laeuft, aber ich haette es gerne weg.

Skystar 2.6C und Hauppauge nexus-s, jede karte hat einen eigenen Anschluss zum Twin-LNB
Treiber 1.1.0 - Problem wurde hier im Forum auch bei 2.6B und 1.1.1 berichtet.

messages:
Apr 9 20:11:00 vdr vdr[1099]: timer 17 (4 2011-2310 'Duell - Enemy at the Gates') start
Apr 9 20:11:00 vdr vdr[1099]: executing '/usr/bin/recordingaction before

"/video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec"'
Apr 9 20:11:00 vdr recordingaction: executing /usr/share/vdr/recording-hooks/R10.noad before recording

/video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec
Apr 9 20:11:00 vdr R10.noad: noad args: /usr/share/vdr/recording-hooks/R10.noad before

/video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec
Apr 9 20:11:00 vdr vdr[1099]: record /video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec
Apr 9 20:11:31 vdr vdr[1099]: timer 17 (4 2011-2310 'Duell - Enemy at the Gates') stop
Apr 9 20:11:31 vdr vdr[1099]: executing '/usr/bin/recordingaction after

"/video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec"'
Apr 9 20:11:31 vdr recordingaction: executing /usr/share/vdr/recording-hooks/R10.noad after recording

/video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec
Apr 9 20:11:31 vdr R10.noad: noad args: /usr/share/vdr/recording-hooks/R10.noad after

/video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec
Apr 9 20:11:31 vdr R10.noad: Friday,09.04.2004 20:11:31 start noad0.3.2b for

/video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec
Apr 9 20:11:31 vdr vdr[1099]: saved setup to /etc/vdr/setup.conf
Apr 9 20:11:31 vdr vdr[1099]: stopping plugin: femon
.........beenden der plugins

Apr 9 20:11:32 vdr vdr[1099]: exiting
Apr 9 20:11:32 vdr runvdr: restarting VDR
Apr 9 20:11:37 vdr kernel: saa7146: unregister extension 'dvb'.
Apr 9 20:11:37 vdr kernel: Linux video capture interface: v1.00
Apr 9 20:11:38 vdr kernel: saa7146: register extension 'dvb'.
Apr 9 20:11:38 vdr kernel: PCI: Found IRQ 10 for device 01:01.0
Apr 9 20:11:38 vdr kernel: PCI: Sharing IRQ 10 with 00:1f.3
Apr 9 20:11:38 vdr kernel: PCI: Sharing IRQ 10 with 00:1f.5
Apr 9 20:11:38 vdr kernel: saa7146_core: found saa7146 @ mem df8fee00 (revision 1, irq 10) (0x13c2,0x0003).
Apr 9 20:11:38 vdr kernel: DVB: registering new adapter (Technotrend/Hauppauge PCI rev2.1).
Apr 9 20:11:39 vdr kernel: probe_tuner: try to attach to Technotrend/Hauppauge PCI rev2.1
Apr 9 20:11:39 vdr kernel: stv0299.c: setup for tuner BSRU6, TDQB-S00x
Apr 9 20:11:39 vdr kernel: DVB: registering frontend 0:0 (STV0299/TSA5059/SL1935 based)...
Apr 9 20:11:41 vdr kernel: Technotrend/Hauppauge PCI rev2.1 adapter 0 has MAC addr = 00:d0:5c:22:9c:4c
Apr 9 20:11:43 vdr kernel: DVB: AV7110(0) - firm f0240009, rtsl b0250018, vid 71010068, app 8000261a
Apr 9 20:11:43 vdr kernel: DVB: AV7110(0) - firmware supports CI link layer interface
Apr 9 20:11:43 vdr kernel: av7110(0): Crystal audio DAC detected
Apr 9 20:11:43 vdr kernel: saa7146_fops: saa7146 (0): registered device video0 [v4l2]
Apr 9 20:11:43 vdr kernel: av7110: found av7110-0.
Apr 9 20:11:43 vdr kernel: saa7146: register extension 'budget dvb'.
Apr 9 20:11:43 vdr kernel: saa7146: register extension 'budget_ci dvb'.
Apr 9 20:11:43 vdr kernel: saa7146: register extension 'budget dvb /w video in'.
Apr 9 20:11:43 vdr kernel: PCI: Found IRQ 5 for device 01:02.0
Apr 9 20:11:43 vdr kernel: PCI: Sharing IRQ 5 with 00:1f.1
Apr 9 20:11:43 vdr kernel: skystar2.c: FlexCopII(rev.130) chip found
Apr 9 20:11:43 vdr kernel: skystar2.c: the chip has 6 hardware filters
Apr 9 20:11:43 vdr kernel: DVB: registering new adapter (Technisat SkyStar2 driver).
Apr 9 20:11:43 vdr kernel: probe_tuner: try to attach to Technisat SkyStar2 driver
Apr 9 20:11:43 vdr kernel: stv0299.c: setup for tuner Samsung TBMU24112IMB
Apr 9 20:11:43 vdr kernel: DVB: registering frontend 1:0 (STV0299/TSA5059/SL1935 based)...
Apr 9 20:11:44 vdr vdr[29876]: VDR version 1.2.6 (ElchiAIO4d) started

......... laden der plugins und *.conf

Apr 9 20:11:44 vdr vdr[29876]: found 2 video devices

...................initialisieren der plugins

Apr 9 20:11:44 vdr vdr[29876]: setting primary device to 1

........starten der plugins

Apr 9 20:11:44 vdr vdr[29876]: switching to channel 1
Apr 9 20:11:45 vdr vdr[29876]: timer 17 (4 2011-2310 'Duell - Enemy at the Gates') start
Apr 9 20:11:45 vdr vdr[29876]: executing '/usr/bin/recordingaction before

"/video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec"'
Apr 9 20:11:45 vdr recordingaction: executing /usr/share/vdr/recording-hooks/R10.noad before recording

/video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec
Apr 9 20:11:45 vdr R10.noad: noad args: /usr/share/vdr/recording-hooks/R10.noad before

/video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec
Apr 9 20:11:45 vdr vdr[29876]: record /video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec

syslog:
Apr 9 20:11:00 vdr vdr[1099]: timer 17 (4 2011-2310 'Duell - Enemy at the Gates') start
Apr 9 20:11:00 vdr vdr[1099]: Title: 'Duell - Enemy at the Gates' Subtitle: '(null)'
Apr 9 20:11:00 vdr vdr[1099]: executing '/usr/bin/recordingaction before

"/video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec"'
Apr 9 20:11:00 vdr recordingaction: executing /usr/share/vdr/recording-hooks/R10.noad before recording

/video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec
Apr 9 20:11:00 vdr R10.noad: noad args: /usr/share/vdr/recording-hooks/R10.noad before

/video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec
Apr 9 20:11:00 vdr vdr[1099]: record /video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec
Apr 9 20:11:00 vdr vdr[1099]: creating directory /video/Duell_-_Enemy_at_the_Gates
Apr 9 20:11:00 vdr vdr[1099]: creating directory /video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec
Apr 9 20:11:00 vdr vdr[1099]: recording to '/video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec/001.vdr'
Apr 9 20:11:00 vdr vdr[27065]: recording thread started (pid=27065)
Apr 9 20:11:00 vdr vdr[27066]: receiver thread started on device 2 (pid=27066)
Apr 9 20:11:18 vdr vdr[1099]: tvonscreen: no translation found for 'TV-OnScreen' in language 1 (Deutsch)
Apr 9 20:11:31 vdr vdr[27065]: ERROR: video data stream broken
Apr 9 20:11:31 vdr vdr[27065]: initiating emergency exit
Apr 9 20:11:31 vdr vdr[1099]: emergency exit requested - shutting down
Apr 9 20:11:31 vdr vdr[27065]: recording thread ended (pid=27065)
Apr 9 20:11:31 vdr vdr[27066]: receiver thread ended on device 2 (pid=27066)
Apr 9 20:11:31 vdr vdr[1099]: buffer stats: 0 (0%) used
Apr 9 20:11:31 vdr vdr[1099]: timer 17 (4 2011-2310 'Duell - Enemy at the Gates') stop
Apr 9 20:11:31 vdr vdr[1099]: executing '/usr/bin/recordingaction after

"/video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec"'
Apr 9 20:11:31 vdr recordingaction: executing /usr/share/vdr/recording-hooks/R10.noad after recording

/video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec
Apr 9 20:11:31 vdr R10.noad: noad args: /usr/share/vdr/recording-hooks/R10.noad after

/video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec
Apr 9 20:11:31 vdr R10.noad: Friday,09.04.2004 20:11:31 start noad0.3.2b for

/video/Duell_-_Enemy_at_the_Gates/2004-04-09.20.11.50.50.rec
Apr 9 20:11:31 vdr vdr[1110]: KBD remote control thread ended (pid=1110)
Apr 9 20:11:31 vdr vdr[1099]: saved setup to /etc/vdr/setup.conf
....EPG bugfix statistics
Apr 9 20:11:31 vdr vdr[1102]: EIT processing thread ended (pid=1102) - master
Apr 9 20:11:31 vdr vdr[1103]: tuner thread ended on device 1 (pid=1103)
Apr 9 20:11:31 vdr vdr[19782]: receiver thread ended on device 1 (pid=19782)
Apr 9 20:11:31 vdr vdr[1105]: EIT processing thread ended (pid=1105)
Apr 9 20:11:31 vdr vdr[1106]: tuner thread ended on device 2 (pid=1106)

............stopping plugins

Apr 9 20:11:32 vdr vdr[1099]: max. latency time 7 seconds
Apr 9 20:11:32 vdr vdr[1099]: exiting
Apr 9 20:11:32 vdr vdr[1099]: emergency exit!
Apr 9 20:11:32 vdr runvdr: restarting VDR

Servus miteinander,

kann die problematik von polykrates -leider- genauso bestätigen.
meine hardware ist ähnlich - wie in der signatur beschrieben.

hier nochma auszug aus der messages:

Apr 10 00:48:02 vdr vdr[25238]: timer 4 (7 0048-0226 'Die Gruft in den Sümpfen') start
Apr 10 00:48:02 vdr vdr[25238]: executing '/usr/bin/recordingaction before "/video/Die_Gruft_in_den_Sümpfen/2004-04-10.00.48.95.95.rec"'
Apr 10 00:48:02 vdr vdr[25238]: record /video/Die_Gruft_in_den_Sümpfen/2004-04-10.00.48.95.95.rec
Apr 10 00:48:33 vdr vdr[25238]: timer 4 (7 0048-0226 'Die Gruft in den Sümpfen') stop
Apr 10 00:48:33 vdr vdr[25238]: executing '/usr/bin/recordingaction after "/video/Die_Gruft_in_den_Sümpfen/2004-04-10.00.48.95.95.rec"'
Apr 10 00:48:34 vdr vdr[25238]: saved setup to /etc/vdr/setup.conf
Apr 10 00:48:35 vdr vdr[25238]: stopping plugin: femon
Apr 10 00:48:35 vdr vdr[25238]: stopping plugin: streamdev-server
Apr 10 00:48:35 vdr vdr[25261]: Streamdev: Server thread stopped
Apr 10 00:48:35 vdr vdr[25238]: exiting
Apr 10 00:48:35 vdr runvdr: restarting VDR
Apr 10 00:48:40 vdr kernel: saa7146: unregister extension 'dvb'.
Apr 10 00:48:42 vdr kernel: Linux video capture interface: v1.00
....
Apr 10 00:48:49 vdr vdr[5714]: timer 4 (7 0048-0226 'Die Gruft in den Sümpfen') start
Apr 10 00:48:49 vdr vdr[5714]: executing '/usr/bin/recordingaction before "/video/Die_Gruft_in_den_Sümpfen/2004-04-10.00.48.95.95.rec"'
Apr 10 00:48:49 vdr vdr[5714]: record /video/Die_Gruft_in_den_Sümpfen/2004-04-10.00.48.95.95.rec

es wird auch eine 001.vdr mit 0 byte erzeugt und dann 002.vdr, 003.vdr .

eintrag im syslog:

pr 10 00:48:02 vdr vdr[25238]: recording to '/video/Die_Gruft_in_den_Sümpfen/2004-04-10.00.48.95.95.rec/001.vdr'
Apr 10 00:48:02 vdr vdr[3627]: recording thread started (pid=3627)
Apr 10 00:48:02 vdr vdr[3629]: receiver thread started on device 2 (pid=3629)
Apr 10 00:48:33 vdr vdr[3627]: ERROR: video data stream broken
Apr 10 00:48:33 vdr vdr[3627]: initiating emergency exit
Apr 10 00:48:33 vdr vdr[25238]: emergency exit requested - shutting down
Apr 10 00:48:33 vdr vdr[3627]: recording thread ended (pid=3627)
Apr 10 00:48:33 vdr vdr[3629]: receiver thread ended on device 2 (pid=3629)
Apr 10 00:48:33 vdr vdr[25238]: buffer stats: 0 (0%) used
...
nach neustart läuft die aufnahme...

wenns dazu verbesserungen, updates gibt freue ich mich sehr darüber!

schöne osterfeiertage und gruß

marpiet

Hallo zusammen,

das im vorigen posting beschriebene problem der neustarts bei timeraufnahmen mit einer SS2 2.6c besteht nach wie vor.

jetzt wollte ich mal das probieren:

Zitat:

Folgende Zeilen aus der Readme
kann ich wegen mangelnder Englischkenntnisse nicht 100% deuten:
Note 2: you must keep ?zap running, or the frontend will go to sleep
(unless you load dvb-core.o with dvb_shutdown_timeout=0)
Heißt das, das die Karte sich schlafen legt wenn sie nicht im direkten Zugriff ist?

Ja, und zwar nach einem Timeout, der in dvb_shutdown_timeout angegeben wird.
Zitat:

Und wenn ja was kann man dagegen tun?
Die Option dvb_shutdown_timeout=0 brachte keine Änderung.

wo finde ich bitte diese option??
hat schon jemand neue erfahrungen mit den neustarts??

ein weiteres problem scheint mir auch damit zusammenzuhängen:

bsp.: vdr-start 18.00 h mit timeraufnahme premiere (also nexus-s mit ci), dann live -tv auf ard,zdf ... (wohl über skystar 2), dann aufnahmen ansehen...

gegen 23.00 h versuch im osd-menü vdr herunterzufahren -

nur er tut es nicht !!! keine auffälligkeiten in messages und syslog!
es kommt nur der gelbe balken "system wird heruntergefahren" - die meldung "taste drücken, um shutdown abzubrechen" kommt NICHT!
es sind übrigens keine timer in der nächsten stunde programmiert.
erst nach einem neustart des vdr lässt er sich anstandslos herunterfahren.

also ich denke, dass das auch an der "eingeschlafenen" sky star 2 liegt - nur was kann ich dagegen tun??

danke für eure hilfe.

gruß

marpiet

Hallo,
ich bin mit dem Problem auch noch nicht weiter gekommen, nur habe ich festgestellt, dass die kritische Zeit bei 15 Minuten liegt. Ist der vdr länger in Betrieb, dann tritt das Problem auf, ist er erst vor 15 min. oder kürzer gestartet, geht alles ohne Neustart .
Wo stelle ich denn diese Option "dvb_shutdown_timeout=0" ein? In der /etc/modules.conf ? Da finde ich aber keinen Abschnitt über die skystar.
Wer weiss noch was?

Vielleicht hat ja noch jemand Interesse an einer Problemlösung.

Bei mir ist die Karte seit 2 Stunden 37 Minuten ohne sich zu verabschieden
in Betrieb.

Hab gestern mal den neuesten Treiber aus dem CVS-Bereich installiert,
keine Änderung, Karte ist nach ca. 30 Minuten weg. Hab mich heute
mal ein bisschen mit der Latency Zeit auf dem PCI-Bus beschäftigt.
Diese ist bei meinem ASRock-Board Standartmässig auf 32 eingestellt,
hab sie jetzt auf 128 gesetzt und die Karte ist immer noch ansprechbar.

"PCI Latency Timer" was ist das?

Dieser Menüpunkt steuert, wie lange jedes PCI-Gerät den Bus halten
kann, bevor ihn ein anderes übernimmt. Bei höheren Werten kann
jedes PCI-Gerät für eine längere Zeit Transaktionen ausführen und
somit die effektive PCIBandbreite optimieren. Im Interesse einer
besseren PCI-Performance sollten Sie höhere Werte einstellen. Die
Einstellungen können in 32er Schritten von 32 bis 248 reichen.

Läuft jetzt seit 4 Stunden 40 Minuten!
Zwischendurch für ca. 45 Minuten keine Aktivitäten auf der Karte.

Hab grad nen Stream übers Netz gestartet, nix, Karte hat sich wieder
verabschiedet. So'n Sche**!
Latency auf 160 gesetzt, mal sehn.

Wenn ich meine proc/pci ansehe, hat die SS2 gar keinen latency parameter. Ich habe bei mir auch die Zeit auf 128 hochgesetzt und es hat nichts gebracht, ausser dass jetzt der Empfang schlecht ist, was aber auch am Wetter liegen könnte. Morgen mal sehen.

Ich tippe immernoch auf den DVB Treiber.
Weil, bis vor kurzem hatte ich keine FF sondern nur ne dxr3 + SS2.
Als ich das system letztes jahr anfänglich installiert habe hatte ich das problem nicht. Sprich mann konnte stundenlang MP3´s hören (in dem fall bleibtz die SS2 dann ja auch unbenutzt) und danach ganz normal TV schauen. Erst nach einem update der DVB Treiber ende letzten Jahres ist es dann immer passiert das das Bild nach dem MP3 hören schwarz blieb.
Kann das nicht evtl mal einer überprüfen? Evtl. was die da an den Treibern gemacht haben zu der Zeit?