Hauppauge NOVA-T 500 fällt nach einiger Zeit aus

genau das haben wir Dir doch schon empfohlen... mach das doch mal bitte...

Ja bei der Hauppauge Nova-T 3 ist es das selbe, wobei meine nur einen Tuner hat.
lsusb

Bus 001 Device 012: ID 2040:7070 Hauppauge Nova-T Stick 3

lsmod | grep dvb

dvb_usb_dib0700        76881  11 
dib7000p               26428  2 dvb_usb_dib0700
dib0090                21348  1 dvb_usb_dib0700
dib7000m               17340  1 dvb_usb_dib0700
dib0070                12736  2 dvb_usb_dib0700
dvb_usb                22011  1 dvb_usb_dib0700
dib8000                26172  1 dvb_usb_dib0700
dib9000                26441  1 dvb_usb_dib0700
dvb_core               67624  4 dib7000p,dvb_usb,dib8000,dib9000
dib3000mc              17426  1 dvb_usb_dib0700
rc_core                17813  12 dvb_usb_dib0700,ir_lirc_codec,ir_mce_kbd_decoder,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,ir_nec_decoder,rc_imon_pad,imon,dvb_usb
dibx000_common         12917  6 dvb_usb_dib0700,dib7000p,dib7000m,dib8000,dib9000,dib3000mc
i2c_core               18989  12 dvb_usb_dib0700,dib7000p,dib0090,dib7000m,dib0070,dvb_usb,dib8000,dib9000,dib3000mc,dibx000_common,nvidia,i2c_nforce2
usbcore                99058  12 btusb,dvb_usb_dib0700,lirc_imon,imon,dvb_usb,usbhid,usb_storage,uas,ohci_hcd,ehci_hcd

uname -a

Linux xbmc 2.6.38-bpo.2-686 #1 SMP Tue Jun 14 11:43:18 UTC 2011 i686 GNU/Linux

Im media_tree hat sich in diesem Bereich seit Monate nichts geändert und in der Mailinglist ist der dib7000 kein Thema. Ohne EPG-Search ist für mich keine Alternative, genau so wenig wie tvheadend. Das VDR in der "Lage" ist den Treiber in so einen Zustand zu bringen deutet für mich aber auch auf einen Bug in Treiber hin.

Zitat von Telperiar

...Ohne EPG-Search ist für mich keine Alternative...

EPG ist nicht gleich EPG - mir pers. war der "normale" EPG immer schon zu wenig aussagekräftig - gerade was das EPG-Search anging - ich hab so ein paar Lieblingsschauspieler - und die werden oftmals im normalen EPG gar nicht aufgeführt... - deshalb habe ich schon seit immer t***2vdr der beim besten freund noch immer schön passend liegt...

Das Problem mit den Dualtuner Dibcom's ist ne olle Kammelle. Machmal hilft auch die Forensuche:

http://www.vdr-portal.de/board…it-nova-t-500-und-nova-td

Dort gibts auch nen Patch für den vdr 1.6, der den EIT Scan für die Zeit einer Aufnahme verhindert. Damit hats dann bei mir ohne Probleme funktioniert.

Das Problem liegt nicht am Treiber, sondern bei der Dibcom Firmware, so zumindest die Aussage von Patrick Boetcher, dem Treiberentwickler.

Zitat

Im media_tree hat sich in diesem Bereich seit Monate nichts geändert

Nein.

http://www.marcet.info/2011/08…tions-in-2-6-39-1-and-3-0

Sind seit maximal 1-2 Monaten eingeflossen.

Zitat von Midas

http://www.marcet.info/2011/08…tions-in-2-6-39-1-and-3-0
Sind seit maximal 1-2 Monaten eingeflossen.

Die Raceconditions sind ein anderes Problem und treten erst ab Kernel 3.0.0 auf und zwar bei allen Dibcom Devices, nicht nur bei den Doppeltunern. Die Patches sind nicht in 3.1 und wie es ausschaut auch nicht 3.2 enthalten, obwohl sie eigentlich im git von v4l entsprechend getagged sind.

Ich wollte auch nicht auf den epg-scan hinaus, sondern auf die race conditions in Verbindung mit dem Thread-Titel / oggers Problem. Habe gerade gesehen, dass er noch Kernel 2.6.38 hat. Von daher, wird es wohl ein anderes Problem sein, ja. Mit media-build habe ich letztens einen tree gezogen, der die race condition patches enthält bzw. dort zumindest sind sie drin.

EPG Scan nicht Search Ich weiss nicht ob EPG Scan die Karte heiss macht (ich kann mich schlecht in DVB Karten reinversetzen) - auf jedenfall ist der EPG Scan ein harte Prüfung für DVB Karten weil quasi Powerzappen simuliert wird.

Zitat von oggers

Aber warum gibt es eigentlich noch nicht eine Lösung (Patch) wie zum Beispiel den EPGSearch abschalten wenn es eine Aufnahme gibt?
Irgendwo hab ich gelesen dass ein Lüfter geholfen hat. Kann es sein dass ein EPGSearch die Karte heiss macht und dann fällt sie aus?

Warum solte im VDR ein Workaround für fehlerhafte Soft/Firmware enthalten sein? Ich denke nicht,dass es ein Temp Problem ist, sondern eine RaceKondition innerhalb der Firmware oder ein DesignProblem der Hardware.

Nur wenn das Problem im Treiber, oder in der Firmware liegt. Warum ist dann VDR betroffen, TVheadend aber nicht? Und wieso kann ich meinen dib7000 (Single-Tuner) Stick wieder in einen Empfangsfähigen Zustand versetzen in dem ich eine Aufnahme erzwinge? VDR stürzt dann nach einigen Sekunden ab, und zeigt nach einem automatischen Neustart wieder ein Bild. VDR so neu zu starten funktioniert hingegen nicht, auch dann nicht wenn es mit an und abstecken des DVB-Sticks kombiniert wird.

Zitat von Telperiar

VDR stürzt dann nach einigen Sekunden ab, und zeigt nach einem automatischen Neustart wieder ein Bild.

Stürzt er wirklich ab?

In den Einstellungen kannst du einen "Notausstieg" aktivieren. Dann beendet er sich ("beenden" nicht "abstürzen") mit einen bestimmten Exitcode wenn bei ner Aufnahme Empfangsprobleme festgestellt werden, die üblichen VDR Startscripte reagieren beim Beenden mit diesem Exitcode üblicherweise damit die DVB Treiber zu entladen, neu zu laden und den VDR wieder zu starten.

Und das Treiber entladen und neuladen muss für deinen Fall evtl. angepasst werden wenns da bei dir Probleme gibt. Weil evtl. reicht es ja nich nur den DVB Treiber zu enladen, evtl. reisst es auh was anderes mit runter?

cu

Ich denke hier wurde schon alles gesagt um der Sache auf den Grund zu gehen. Der EPG Scan "tötet" die Karte. Ein neuladen der Treiber versetzt den Treiber wieder in einen funktionsfähigen Zustand. Wenn keine Aufnahme ansteht "merkt" der VDR nicht das er keine Daten von der Karte bekommt, dementsprechend schlägt der watchdog nicht zu.

Generell gibt es da auch einen anderen/besseren Weg um das ganze zu handhaben als den Watchdog des VDR anspringen zu lassen. Es gibt nur nicht allzuviele Karten die solche Probleme haben, deswegen ist das nicht richtig ausgearbeitet.

in /etc/vdr/plugins/plugin.dymite.conf müsste dieses:

--GetTSTimeoutHandler=/path/to/program
    set program to be called on GetTS-timeout

entsprechend belegt werden.

Und eine entsprechende udev-Rule gesetzt werden(siehe "# switch on monitoring SkyStar 2 2.6"):
# cat /lib/udev/rules.d/40-dvb-device-other.rules

# ignore usb devices
SUBSYSTEMS=="usb", GOTO="end"


# fill DVBMODULE with modalias or module name for frontend
KERNEL=="dvb?.frontend?", ATTRS{modalias}=="*", ENV{DVBMODULE}="%s{modalias}"


# switch on monitoring SkyStar 2 2.6
ENV{DVBMODULE}=="pci:v000013D0d00002103sv000013D0sd00002103bc02sc80i00", ENV{dynamite_timeout}="10", ENV{dynamite_timeout_handler_arg}="%E{DVBMODULE}"


LABEL="end"

Dann kann im laufenden VDR die Karte rausgelöst werden und die Treiber neu geladen werden. Aber das ist nur richtig interessant wenn neben dieser Karte noch andere Karten sind welche normal weiter funktionieren. Und diese Karte bräuchte dann wohl ein spezielles Script um beide Devicenodes des Gerätes auszuhängen und nur diesen Treiber plus abhängige Module neu zu laden.

Zitat von Telperiar

Und wieso kann ich meinen dib7000 (Single-Tuner) Stick wieder in einen Empfangsfähigen Zustand versetzen in dem ich eine Aufnahme erzwinge?

Wieso Singletuner? Hier gehts doch um Probleme bei den Dualtuner-Devices und darauf beziehen sich auch meine Aussagen.

BTW in Kernel 3.1.1 ist endlich der Fix drin, der das Racekonditionproblem seit 3.0.0 behebt.

Zitat von glotzipapa

Wieso Singletuner? Hier gehts doch um Probleme bei den Dualtuner-Devices und darauf beziehen sich auch meine Aussagen.

BTW in Kernel 3.1.1 ist endlich der Fix drin, der das Racekonditionproblem seit 3.0.0 behebt.

Das von steffen beschriebene Fehlerbild trifft bei meinem Nova-T Stick eindeutig zu. Den Stick gibt es auch als Nova-TD mit Dualtuner, allen gemein ist aber der Chipsatz.

Leider kann ich das Problem schlecht analysieren weil das sehr unregelmäßig auftaucht. Das läuft schon mal eine Woche problemlos, oder passiert an zwei Tagen nacheinander. Die meisten Alternativen Lösungen im Thread helfen mit nur eingeschränkt, da mache ich mehr Problemfelder auf als ich schließe. Bei EPG über Internet-Dienste etwa die Zeichenkodierung, oder fehlende Genres in XBMC. Inoffizielle Kernel unter Debian sind auch immer so eine Sache, bei 2.6.38bpo änderte sich z.B. das imon-Handling total.

Did you find a solution to this issue, beyond disabling EPG scan? I frequently see tuner 1 loose the signal at random times, and the only way to get anything shown is to go into Femon and change to one of the other tuners. I run with two nova-t 500 cards.