frontend timed out while tuning to channel

  • Jetzt, habe ich dich wohl richtig verstanden, Joe_D ...

    Damit scheint es jetzt zu funktionieren:

    has_ts in Zeile 92 ohne Abfrage auf 1 zu setzen, hilft nicht.

    Ob das richtig ist oder Nebenwirkungen hat, darfst du entscheiden ;)

  • So habe ich es jetzt bei mir:

  • und jetzt kam damit aber ein kernel NULL pointer dereference:


  • Danke. Habs drauf. Schaut gut aus und werds beobachten.

  • Kurzes Update...


    Hier mal ein vollständiges Log, wie eine Nacht headless VDR bei mir so aussieht:

    http://imkreisrum.de/up/vtuner_filtered.log


    Die timeout Meldungen sind erstmal weg, aber jetzt habe ich folgendes im Log:

    Code
    Jan 26 20:53:29 server01 vdr[25830]: [25851] frontend 3/0 is not receiving transponder 210847 for channel 822 (TEST RA) - retuning
    Jan 26 20:53:29 server01 vdr[25830]: [25848] SDT: channel 822 NID/TID (1/1058) not found, got 1/1117

    Ob das "bedenklich" ist, kann ich nicht sagen.


    Die incomplete section Meldungen hatte ich immer mal wieder. Müsste es hier auch einen Thread dazu geben.

    Code
    Jan 26 22:06:32 server01 vdr[25830]: [25853] frontend 4/0 regained lock on channel 761 (SYFY HD), tp 112305
    Jan 26 22:06:32 server01 vdr[25830]: [25853] frontend 4/0 lost lock on channel 761 (SYFY HD), tp 112305

    kommt von den sundteks, aber das sehe ich nicht tragisch.


    Das vdr-manager plugin prodziert um 20:56:30 einen invalid lock, aber damit beschäftige ich mich später.


    Was als neues Problem auftritt, zumindest wäre es mir vorher nicht aufgefallen, ist der kernel Speicherfehler mit dem null pointer um 04:46:14.

    Das betrifft wohl frontend 1/0, weil erst danach die timeout Meldungen darauf kommen. Es funktioniert erst wieder, wenn ich das Kernelmodul ent- und neu lade. Allerdings schaut die letzte Änderung an vtuner-ng nicht so aus, als hätte sie diesen Bug eingeführt. Kann ich das weiter debuggen, oder sieht jemand auf Anhieb, was das falsch läuft.

  • Laut gdb, ist das hier:

  • Damit

    kann ich jetzt dem ctx->demux.feed[idx].priv die Schuld geben. Warum auch immer scheint das ein nullptr zu sein:

    Code
    Jan 29 14:17:01 server01 kernel: BUG: kernel NULL pointer dereference, address: 00000000
    Jan 29 14:17:01 server01 kernel: vtunerc3: !fi
    Jan 29 14:17:01 server01 kernel: vtunerc3: i 1128 offs 4 pf 0
  • Ja. Während vtuner_ctrldev_write schneit ein stop_feed rein...

  • Als schneller Workaround funktioniert das hier bei mir:


  • Funktioniert jetzt. Danke.


    Jetzt habe ich "nur" noch folgende Meldungen:

    Code
    Jan 31 14:37:19 server01 vdr[6661]: [6689] SDT: channel 393 NID/TID (1/1054) not found, got 1/1113
    Jan 31 14:37:20 server01 vdr[6661]: [6692] frontend 1/0 is not receiving transponder 210788 for channel 393 (ALQUILER 1) - retuning
    Jan 31 14:38:01 server01 vdr[6661]: [6697] SDT: channel 898 NID/TID (1/1004) not found, got 1/1040
    Jan 31 14:38:02 server01 vdr[6661]: [6700] frontend 3/0 is not receiving transponder 211259 for channel 898 (M+LCAMPEONES) - retuning

    Auf dem headless (i686) Server mit 4 vtuner-devices + 2 sundteks habe ich ca. 30 SDT-Meldungen pro Stunde und auf dem rockchip mit 2 vtuner (einer davon für LIVE-TV), also nur einer für den EPG-Scan, ca. 1 SDT Meldung pro Stunde...

    Seltsamerweise wird hier auch der channel 0 angemeckert. Was ist denn der Channel 0?



    Zusätzlich kann ich auf dem dem Server ca. 50-60 incomplete section Meldungen pro Stunde reproduzieren, wenn 2 sundtek-Sticks mit im Spiel sind. Die length Meldungen betreffen aber nur folgende transponder: 12552 und 11778. Mit reiner vtuner-Versorgung habe ich die Meldungen nicht.

    Code
    Jan 31 14:38:52 server01 vdr[6661]: [6703] tp 211778 (18/FF) read incomplete section - len = 4098, r = 4096
    Jan 31 14:39:54 server01 vdr[6661]: [6703] tp 212552 (18/FF) read incomplete section - len = 4098, r = 4096
    Jan 31 14:40:12 server01 vdr[6661]: [6703] tp 212552 (18/FF) read incomplete section - len = 4098, r = 4096

    Ich würde gerne beide Probleme lösen ;) Und stelle mir die Frage, was die Meldungen überhaupt sagen und wie ich das Problem debuggen kann?

    Ich hatte hier das Thema schonmal andiskutiert, aber ich glaube, ich bekam es damals nicht gelöst. Ich setze jetzt mal die FLUSH_TIME testweise auch auf 500ms..


    Hat noch jemand die Probleme oder kann mir Tips geben? 1 Log/Stunde stört mich nicht, 60 schon...

  • Code
    Feb 01 09:51:07 server01 vdr[30550]: [30550] EIT scan: device 5  source  S19.2E   tp 211778
    Feb 01 09:51:10 server01 vdr[30550]: [30567] creating new channel 'DW English HD,;Deutsche Welle' on S19.2E transponder 211778 with id 1-1068-5700-0
    Feb 01 09:51:10 server01 vdr[30550]: [30567] creating new channel 'TVMonaco,;EasyTools' on S19.2E transponder 211778 with id 1-1068-5701-0
    Feb 01 09:51:10 server01 vdr[30550]: [30567] creating new channel 'Cubavision Internacional,;OVERON' on S19.2E transponder 211778 with id 1-1068-5703-0
    Feb 01 09:51:10 server01 vdr[30550]: [30567] creating new channel 'CNN Int.,;SES ASTRA' on S19.2E transponder 211778 with id 1-1068-5710-0
    Feb 01 09:51:12 server01 vdr[30550]: [30567] changing pids of channel 1030 (DW English HD) from 0+0=0:0:0:0 to 1110+1110=27:1120=eng@3:0:0
    Feb 01 09:51:12 server01 vdr[30550]: [30567] changing pids of channel 1031 (TVMonaco) from 0+0=0:0:0:0 to 110+110=27:121=fra@3,122=qaa@3,123=qad@3:0:141
    Feb 01 09:51:12 server01 vdr[30550]: [30567] changing pids of channel 1032 (Cubavision Internacional) from 0+0=0:0:0:0 to 708+708=27:728=esl@3:0:0
    Feb 01 09:51:13 server01 vdr[30550]: [30567] changing pids of channel 1033 (CNN Int.) from 0+0=0:0:0:0 to 95+95=2:48=eng@3:0:0
    Feb 01 09:51:24 server01 vdr[30550]: [30567] tp 211778 (18/FF) read incomplete section - len = 4098, r = 4096



    Also, ich würde das jetzt auf ein Problem mit dem Transponder schieben. Alle Kanäle auf 11778 und 12552 gelöscht, EPG Scan findet die Kanäle und dann kommt gleich der Fehler. Device 5 ist ein sundtek Stick.

  • Ergänzung: Derselbe Test nochmal ohne die beiden sundtek Sticks.

    Auch hier werden die Kanäle gefunden und angelegt, aber die incomplete section Meldung bleibt aus.


    Es liegt also definitiv am Verhalten der Sticks mit den beiden Transpondern. vtuner wäre damit als Ursache raus.

    Sundtek Irgendwelche Ideen?


    Kann das ausser mir noch jemand so reproduzieren?


    EDIT: HelmutB hat hier eine Vermutung zu den sundteks geäußert: RE: [Patch] "read incomplete section" und dmxdev.c ringbuffer


    Bei den Frequenzen 12552 und 12551 würde ich mal sagen, das ist dasselbe Problem.

    Einmal editiert, zuletzt von rell ()

  • Kannst Du eventuell mal nen remote Zugang zu dem System bereitstellen?

    Was ich da machen würde wäre ein kleines Testprogramm mit entsprechenden Filtern, vielleicht wird da irgendetwas gematched was im Filter eigentlich nicht gematched werden sollte. Wir haben einen eigenen Demuxer in der Software-Chain, der hat einige spezielle Features für spezielle Anwendungen.

    Hat Das bei Dir sonst irgendwelche Nebenwirkungen?


    Wenn ich hier einen EIT Filter auf diesen Transponder loslasse sehe ich keine Probleme (aber ich kenne halt auch nicht die genauen Filter Settings die VDR da loslässt und auf diese wird es ankommen).

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!