Beiträge von Joe_D

  • [vtuner-ng] Aktualisierter vtuner für kernel >= 4.16

    Hab das heute mal extra eingerichtet mit zwei Tunern - wobei die Fritte ohne SAT>IP-Zertifizierung natürlich gleich mal den Frontend-Parameter genüßlich ignoriert (-f)

    Code
    /usr/sbin/modprobe vtunerc devices=2 
/usr/local/bin/satip -s fritz.box -d /dev/vtunerc0 -D DVBC -m 2 -l 4 -f 4 -r 45000 2> /tmp/satip0.log &
/usr/local/bin/satip -s fritz.box -d /dev/vtunerc1 -D DVBC -m 2 -l 4 -f 3 -r 45002 2> /tmp/satip1.log &

    Umschalten auf ZDF ohne HD ergibt (mit framebuffer-xineliboutput) ein Bild:

    Code
    Apr 11 16:04:35 vdr2 vdr: [3185] switching to channel 200 C-1-1079-28006 (ZDF)
Apr 11 16:04:35 vdr2 vdr: [3249] device 2 receiver thread started (pid=3161, tid=3249, prio=high)
Apr 11 16:04:35 vdr2 vdr: [3250] device 2 TS buffer thread started (pid=3161, tid=3250, prio=high)
Apr 11 16:04:35 vdr2 vdr: [3161] [xine..put] cXinelibOsd::CanHandleAreas(): Device does not support ARGB
Apr 11 16:04:35 vdr2 vdr: [3249] [xine..put] Detected video size 720x576

    Dabei wird das in vtunerc1 ausgegeben:


    Gleichzeitig habe ich auf dem anderen Tuner eine Aufnahme auf SR-Fernsehen SD gestartet.


    Das sieht dann so in der Fritzbox aus:

  • Neverending EPG scan?

    Zitat von kls

    bitte schau dir mal beiliegende Fassung an und sag Bescheid, ob das so OK wäre.


    Funktioniert, eingestellt waren zwei Stunden Pause:

    Code
    Mar  5 07:06:06 server vdr: [6669] EIT scan: 37 scanList entries
Mar  5 07:06:06 server vdr: [6669] EIT scan: 37 device 1  source  S19.2E   tp 110891
[...]
Mar  5 07:13:21 server vdr: [6669] EIT scan: 1 device 1  source  S19.2E   tp 212480
[PAUSE]
Mar  5 09:13:42 server vdr: [6669] EIT scan: 37 scanList entries
Mar  5 09:13:42 server vdr: [6669] EIT scan: 37 device 1  source  S19.2E   tp 110891
[...]
Mar  5 09:20:00 server vdr: [6669] EIT scan: 1 device 1  source  S19.2E   tp 212480

  • Neverending EPG scan?

    Zitat von kls

    Joe_D

    Was genau hat es denn mit 'firstCall' auf sich?

    Ist das nicht bereits dadurch klar, ob es eine scanList gibt?

    Übersehe ich da was?

    scanList ist zu Anfang leer, die Prüfung ob eine Pause gemacht werden soll wird gemacht wenn scanList (wieder) leer ist. Damit nicht gleich zu Anfang gewartet wird habe ich das Flag 'firstCall' eingefügt damit eine optionale Pause nur nach erstmaligem Scan eingelegt wird.

  • Neverending EPG scan?

    Zitat von rell

    Ich denke, streamdev handelt das anders

    Oje, noch so ein Gebastel. Schöner wär natürlich das Aussenden von Sections ...


    Zitat von rell

    mich stört nur, dass hier das Log geflutet wird, aber das ist ja leicht zu beheben.

    Richtig, das ist ja auch nur drin um das Verhalten des Patches zu visualisieren und kann auskommentiert werden

  • Neverending EPG scan?

    Zitat von rell

    nur streamdev. Hat der Patch damit ein Problem?

    Nö, der Patch hat kein Problem :) Der macht nur zwei Dinge ggü. der Standard-Version: Nimmt optional nicht alle Kanäle und/oder wartet optional nach einem erfolgtem Scan X Stunden. Nicht weniger aber auch nicht mehr...


    Hab' keine Ahnung und Verwendung für streamdev, aber wenn das hier die Sourcen vom streamdev-Device sind... ja dann finde ich das hier nicht:


    Code: device.h
      virtual bool ProvidesEIT(void) const;
         ///< Returns true if this device provides EIT data and thus wants to be tuned
         ///< to the channels it can receive regularly to update the data.
         ///< The default implementation returns false.


    Aber das wäre IMHO halt für den scan nötig:

    Code: eitscan.c
        if (Device && Device->ProvidesEIT()) {

  • Gibt es eine Alternative zu DVB-C welche mit VDR funktioniert?

    Zitat von FJe

    eine verbindung zum vdr wäre super, weil man dann ohne kabel-tv mit dem hohen komfort weitermachen könnte.

    Da ich von dem ganzen "Stick"-Zeugs keine Ahnung habe - selbst auch noch nie so einen Stick in Verwendung hatte - habe ich mir mal die Anleitung von dem waipu-Stick angeschaut. Also im Endeffekt handelt es sich (wenn man mal in Uralt-Analogien sprechen möchte) wie damals in meinen jungen Jahren um einen SAT-Premiere-Receiver mit Smartcard. Nur statt SAT-Anschluss WLAN und statt Smartcard irgendein eingebautes DRM-Decodergedöns. Am HDMI-Anschluss kommt dann "nur" Bild und Ton des gerade angewählten Senders raus. Also in VDR-Analogie ein Singletuner-Gerät.


    Und das soll nun "irgendwie halt" in 'nen VDR rein, weil der ja so 'ne dolle Aufnahmefunktion hat. Ok.


    Wenn ich mir das von der VDR-Seite her überlege sehe ich da nur Gebastel und Gemurkse auf allerhöchstem Raspberry Pi Niveau.


    Für Aufnahmen braucht der VDR


    1. eine Möglichkeit Kanäle anzuwählen
    2. einen Stream im TS-Format
    3. ein EPG mit Programm-Infos zum angewählen Kanal


    zu 1) Kanäle anwählen wird schonmal schwierig, da Waipu zum Stick keine API anbietet mit der man sowas "einfach" bewerkstelligen könnte. Gefunden habe ich nur das es im April 2023 dazu keine Möglichkeit gab. Zweite Möglichkeit wäre nun einen IR-Sender am VDR anzubringen der die Fernbedienung für den Waipu-Stick "bedient" und Kanäle umschaltet. Stelle ich mir ulkig vor. Brauchts natürlich noch ein entsprechendes Waipu-Device-Plugin dazu..


    zu 2) soll ja Kästchen von Exvist und anderen geben die aus HDMI einen TS-Stream in vielen verschiedenen Formaten ausgeben können. Könnte mit dem satip-Plugin empfangbar sein. Schon der Gedanke was das für ein höllisches Gebastel ist weil das satip-Plugin ja eigentlich davon ausgeht einen vollständigen Tuner mit Umschaltbarkeit + Empfang von EPG zu haben. Also doch eher wieder in Richtung spezielles Waipu-Device-Plugin das nur den TS-Stream empfängt, nix umschaltet und kein EPG empfängt. Und zu guter Letzt: Wird DRM-geschütztes Zeug eigentlich von den Kästchen überhaupt konvertiert?


    zu 3) da schon zu 1) nix vorhanden ist, kann man also auch das Waipu-Stick interne EPG nicht anzapfen. Da besteht dann im VDR die Möglichkeit (auch nur über ein spezielles Waipu-EPG-Plugin) irgendein EPG von irgendeiner Quelle auszulesen und in den VDR einzupflegen. Auch hier tut mir der Kopf weh wenn ich an das endlose Gebastel denke bis für alle Kanäle das EPG zusammengeflickt ist.


    Dazu braucht es dann noch eine Channel.conf die ebenso wie alles andere zusammengebastelt werden muss, da es ja kein "normales" EPG gibt.


    Allein der Gedanke sowas umzusetzen würde mich die Flucht ergreifen lasssen =O

  • Gibt es eine Alternative zu DVB-C welche mit VDR funktioniert?

    Zitat von Paulaner

    Aber das Thema IPTV wird hier im VDR leider sehr wenig gemacht, liegt aber sicherlich auch daran, das der VDR vom linearen TV herkommt.

    Könnte natürlich auch daran liegen das der VDR standardisierte TS-Streams anhand von Zeitinfos eines standardisierten EPG aufnimmt und Aufnahmen mittels schöner Oberfläche inkl. eigenem OSD ausgibt. Wo die standardisierten Streams oder das standardisierte EPG bei IPTV sein soll konnte ich noch nicht so recht finden. Scheinbar macht da jeder was er will. Deshalb gibt es für Streamingfans Kodi mit den tausenden AddOns, die ich für Mediatheken oder Disney+ selbst auch nutze...

    Zitat von Paulaner

    Im Prinzip bräuchte man nun also etwas, was den VDR in die Lage versetzt, die Daten vom TVheadend zu bekommen.
    Ich hätte nun das Ganze nun am liebsten auf dem VDR verfügbar, da für mein Empfinden die LiveTV- und auch teilweise die Aufnahmefunktionen mit z.B. Suchtimern usw. in KODI nicht ganz so gut gelöst sind, wie das der VDR kann.

    Den Motor vom Porsche hätte ich gern in meinem Mercedes, vorhanden wäre ein Ratschenschlüsselsatz. Wo fange ich an? :/


    Code
    CoreELEC vdr[3920]: [3925] SATIP-ERROR: Detected invalid status code 405: rtsp://192.168.1.3/ [device 0]

    Fehler 405 bedeutet "Method not allowed", das sagt jetzt aber auch erstmal noch gar nix.


    Ist der tvheadend Sat>IP-Server "ganz normal" mit VLC erreichbar?

    Bei VLC unter "Ansicht" -> "Wiedergabeliste" unter "Lokales Netzwerk" -> "Universal Plug'n'Play"??


    Normale SAT>IP-Server werden dort sichtbar, man kann dann einfach die Liste der Kanäle anklicken. So mal als ersten Test.


    Ansonsten ist Wireshark ein gutes Tool um zu schauen was zwischen SAT>IP-Server und satip-Plugin hin und hergeht.
    Oder das Logging erweitern, da muss man aber die satip-Plugin Experten fragen...

  • [vdr-plugin-satip] Ständiger Verbindungsaufbau zum satip-Server?

    Zitat von fnu

    Für mich unverständlich warum hier teils verächtlich darüber geschrieben wird. VDR war nie als Server Service vorgesehen. Ihr macht ihn dazu und wundert Euch über die Auswirkungen, anstatt mit dem Verhaltem bei dem von Euch gewünschten Always-On zu leben

    Na wenn Du (auch) mich meinst da bin ich ja noch einer der rührigsten Vertreter des VDR. Für mich gibt es nicht besseres als den VDR mit OSD. Aber da bin ich höchstwahrscheinlich ein Exot. Viele verbannen den VDR scheinbar auf irgendwelche Serverkistchen, verabscheuen das tolle OSD und hantieren mit Kodi herum. Der VDR wird dann nur noch über ein Webinterface "bedient" und soll seine Aufnahmen ausschließlich als "Stream" rausrücken =O


    Wobei eine Server-Client Aufteilung meiner Meinung nach schon Sinn macht. Die "Ausgabeplugins" habe ich nie verwendet wenn sie mit dem VDR zusammen liefen. Das Ausgabeplugin (damals xine oder softdevice) hatte einen Schluckauf oder stürzte ab, schon waren zwei oder drei Aufnahmen im Hintergrund Schrott. Vom Konzept her für mich ziemlich fragwürdig, aber der Hauptentwickler war ja jahrelang FullFeatured-Fan. Und da hatte man wohl solche Probleme nicht. Ich verwende seit Urzeiten xineliboutput. Wenn das Frontend keine Lust mehr hat -> egal, die Aufnahmen waren bislang immer safe :thumbup:


    Nun hat sich über die Jahre der Trend in Richtung SAT>IP ergeben. Als ich vor ein paar Jahren neu gebaut habe, habe ich auf Netzwerkkabel gesetzt. Mein SAT>IP-Server hat einen Sleep-Modus wenn kein Tuner in Verwendung ist. Das spart bei vier Tunern ca. 20 Watt. Und den finde ich schon sinnvoll und unterstützenswert. Wenn ich z.B. zwei Stunden lang eine Aufnahme anschaue dann braucht es in der Zeit gar keinen Tuner. Und wenn ich Live ohne Aufnahme kucke, dann können sich die drei anderen Tuner meiner Meinung nach schon schlafen legen.

  • [vdr-plugin-satip] Ständiger Verbindungsaufbau zum satip-Server?

    Zitat von stauraum

    Wie kann ich das, so wie es jetzt ist, unterbinden?

    Schwierig. Siehe unten.

    Zitat von stauraum

    Oder ist das ein normales Verhalten?

    Normales Verhalten vom vdr ist ständig auf den Tunern rumnudeln - es sei denn Du hast nur einen Tuner - und nur dann - wirkt die eingestellte EPG-Zeit.

    Zitat von pbg4

    Stichwort litescan patch

    Beim litescan-Patch habe ich nicht ausmachen können das der den EIT-Scan schlafen legt. Dafür kann man andere Sachen einstellen deren Nutzen mir schleierhaft sind... aber das ist ja ein anderes Thema :/

    Zitat von Zabrimus

    Wenn ich das richtig verstanden habe, dann soll der Patch von Joe_D genau das Problem lösen

    Jein. Mein Patch verhilft dem vdr zu einer nachgewiesenen Pause-Funktionalität des EIT-Scan auch bei mehreren Tunern (analog zur Pause bei einem Tuner). Die Tuner selbst bleiben auf dem letzen EIT-Kanal stehen. Die Section-Pids werden (leider) nicht abgemeldet.


    Mit meinem vtuner/satip-Gespann trenne ich nun Tuner nach 60 Sekunden die "nur Section-Pids" empfangen vom SAT>IP-Server.

    Ob das das satip-Plugin auch macht? Keine Ahnung!

  • VDR-2.6.6 ohne Kanal starten lassen

    Ok, nach einigem Gesuche im Quellcode ist es viel einfacher als gedacht: CanReplay einfach auf false lassen solange z.B. der Fernseher aus ist.


    Mit folgender Änderung in device.h vom xineliboutput - Plugin

    Code: device.h
        virtual bool CanReplay(void) const {
            if (m_local) return true;
            if (!m_server) return false;
            if (m_server->HasClients()) return true;
            return false;
    };

    und dieser Anpassung in frontend.h vom xineliboutput - Plugin

    Code: frontend.h
    virtual bool HasClients(void) { return true; };


    erhält man fast das gewünschte Verhalten. Ist ein lokales Frontend aktiv wird immer true zurückgemeldet, bei einem remote Frontend nur wenn mindestens ein Client aktiv ist.


    Das führt nun dazu das beim Start vom vdr / xineliboutput auf keinen Kanal umgeschaltet und damit auch kein SAT>IP-Tuner belegt wird. Umschalten ist in diesem Zustand für das PrimaryDevice nicht möglich ("Error switching to channel x"). Aktiviert man nun ein xineliboutput-Frontend wird der SAT>IP-Tuner belegt und das zuletzt angewählte Programm angezeigt.


    Schaltet man nun das Frontend wieder ab, bleibt der SAT>IP-Tuner leider dauerbelegt weil es kein "Abschalten" gibt. ;( Nur über einen Trick wird der SAT>IP-Tuner wieder freigegeben: Man versucht erneut einen Kanal anzuwählen was scheitert. Dabei wird dann aber der SAT>IP-Tuner freigegeben.

  • [solved] ePidType unbenutzt? -> nur für FF

    Habe mal in der Funkiton cDevice::AddPid Logging eingebaut und mir ist folgendes aufgefallen:


    Beim Schalten auf "Das Erste" bekomme ich folgende Ausgabe:

    Code
    Feb 11 13:54:40 server vdr: [26796] AddPid 5101 5 0
Feb 11 13:54:40 server vdr: [26796] AddPid 5102 5 0
Feb 11 13:54:40 server vdr: [26796] AddPid 5103 5 0
Feb 11 13:54:40 server vdr: [26796] AddPid 5107 5 0
Feb 11 13:54:40 server vdr: [26796] AddPid 5106 5 0
Feb 11 13:54:40 server vdr: [26796] AddPid 5105 5 0


    Sämtliche Pids werden als ptOther (=5) hinzugefügt, anstatt z.B. AddPid(5101, ptVideo, ?) oder AddPid(5102, ptAudio, ?)


    In der channel.conf steht doch welche pid für was ist:

    Code
    Das Erste HD;ARD:11493:HC23M5O35P0S1:S19.2E:22000:5101=27:5102=deu@3,5103=mis@3,5107=qks@3;5106=deu@106:5104;5105=deu:0:10301:1:1019:0


    Im vtuner erkenne ich die ja auch:

    Code
     pid tab          : 5100-PMT* 16-NIT* 17-SDT* 0-PAT* 20-TOT* 18-EIT* 5105-SUB* 5106-AC3* 5107-AUD0* 5103-AUD0* 5102-AUD0* 5101-VID0* (len=12)


    Wie soll sowas funktionieren wenn ptAudio und ptVideo nie gesetzt werden? Prüfung nur auf Replaying?

    Code
    bool cDevice::HasProgramme(void) const
{
  cMutexLock MutexLock(&mutexChannel); // to avoid a race between SVDRP CHAN and HasProgramme()
  return Replaying() || pidHandles[ptAudio].pid || pidHandles[ptVideo].pid;
}


    Wird ePidType überhaupt verwendet?

  • VDR-2.6.6 ohne Kanal starten lassen

    Zitat von SurfaceCleanerZ

    Siehe meine Frage zum Einbau des dynamite-Plugin-Patches in VDR im 2.6.6 Thread

    Ja, persönlich finde ich dynamite als Plugin + Patch auch nicht den Hit. Viel zu invasiv. Core-Funktionalität wandert in ein Plugin das mit der Brechstange arbeitet (Device Array komplett füllen). Die Ladereihenfolge ist plötzlich wichtig, neue dynamite-Schnittstellen, usw. usf. Das alles ist schon etwas "weird"... Klar das das nicht akzeptiert wird.


    Im Endeffekt geht es darum dem cDvbDevice abzugewöhnen nur im Konstruktor das Frontend- und ggf. CA-Device zu öffnen. Also eine Verhaltensweise wie eben Demux- und dvr-Device.


    Mein Ansatz ist eben so wenig wie möglich zu ändern um das gewünschte Ergebnis zu bekommen. Anstatt "litescan patch" der das Originalverhalten des vdrs per #ifdefs "ersetzt" minimale Änderungen in eitscan die das Originalverhalten beibehalten und das gewünscht Verhalten hinzufügen.


    So ähnlich habe ich mir das auch für cDevice::SwitchChannel gedacht. Eine neue Funktion virtual bool CanViewProgramme(void) const; die standardmäßig true zurückgibt und die dann vom PrimaryDevice auf false gesetzt werden kann wenn das Ausgabeplugin "schläft" :)
    In SwitchChannel aber auch in der Mainloop kann das mit abgefragt werden.

  • VDR-2.6.6 ohne Kanal starten lassen

    Zitat von MarkusE

    Also kastrieren tut mein Patch nichts, mit Ausgabeplugin ändert der Patch nichts. Und ohne Ausgabeplugin werden dir TS Daten ja nicht benötigt.

    Achso, tut mir leid dann habe ich das falsch verstanden :O


    Zitat von MarkusE

    Da bräuchte man:

    - Patch in VDR, der ein Interface zum Ein/Ausschalten der TS Daten beim primary device nachrüstet

    - Patch in den Ausgabeplugins, die dieses Interface aufrufen.

    Ja und zusätzlich eben eine Funktion die im cDevice den Kanal "abwählt" cDevice::ClearChannel gefällt mir da gut als Bezeichnung

  • VDR-2.6.6 ohne Kanal starten lassen

    MarkusE Danke für den Link


    Ich möchte aber nix kastrieren, sondern im Endeffekt bestehendes verbessern. Eine sowohl-als-auch-Lösung. Also Sektionhandler nach einem EPGScan stoppen. Transfermode und Sektionhandler nach einer Aufnahme oder nach Abschalten des Ausgabeplugins stoppen. Das müsste ja dann ebenso bei Servern ohne Ausgabeplugin funktionieren.

  • VDR-2.6.6 ohne Kanal starten lassen

    An meinem Test-VDR verwende ich das xineliboutput-Plugin mit "Remote" frontend auf der gleichen Kiste.

    Das Frontend wird nur gestartet, wenn der Bildschirm an ist bzw. wird beides mit der Fernbedienung angeschaltet.


    Bisheriges "vanilla" Verhalten war, das eine Minute nach dem Start vom VDR grundsätzlich alle SAT>IP Tuner dauerbelegt sind bis "in alle Ewigkeit" bzw. bis der VDR wieder abgeschaltet wird, leider unabhängig der "äußeren" Bedingungen:

    • Automatischer Start wegen Aufnahme (erstmal kein Kanal benötigt)
    • manueller Start um sich per ssh einzuloggen (erstmal kein Kanal benötigt)
    • manueller oder automatischer Start, zusätzlich Start des Frontends per Fernbedienung (Kanal benötigt)


    Mein Patch von hier führt schonmal dazu das nicht ständig sämtliche Tuner in Verwendung sind und der EITScan nach dem ersten Durchlauf ein Päuschen einlegt. Dadurch kann der vtuner diese SAT>IP-Tuner freigeben.


    Mit diesem kruden "Holzhammer"-Patch habe ich meinen vdr dazu bekommen gänzlich ohne Kanal zu starten:


    Das führt nun zu folgendem Verhalten: VDR startet und belegt erstmal keine SAT>IP-Tuner, nach einer Minute wird der EPG-Scan auf allen SAT>IP-Tunern gestartet. Nach dem ersten Durchlauf werden alle SAT>IP-Tuner von vtuner wieder freigegeben (Erkennung nur Section-Pids mit Timeout 60 Sekunden), der VDR selbst lässt die SAT>IP-Tuner lustig weiter senden. Startet eine Aufnahme wurde bei mir ein SAT>IP-Tuner belegt und nach der Aufnahme nie wieder freigegeben ;(


    Einziger Nachteil: Fernsehbild erscheint nun erst nach einmaligem Umschalten, da ja von Haus aus erstmal kein Kanal angewählt ist. Die Frage ist ob ein Ausgabeplugin (xineliboutput) dem VDR mitteilen kann das sich ein Ausgabefrontend verbunden hat und damit dann auf den zuletzt verwendeten Kanal geschaltet wird.


    So wie ich es bis jetzt sehe gibt es nur ein "anschalten" von allem, aber kein "abschalten". Im Endeffekt läuft alles über cDevice::SetChannel, dort wird vor dem Umschalten der alte Kanal abgeschaltet. Ein cDevice::UnSetChannel oder cDevice::ClearChannel das die SectionHandler beendet und beim PrimaryDevice zusätzlich StopReplay aufruft gibt es leider nicht ;(

  • Neverending EPG scan?

    Zitat von Joe_D

    Das habe ich dann zu restriktiv gemacht. Ich denke die Einträge aus der cTransponderList die vom NIT-Sectionfilter gesetzt werden muss ich mit einer Ausnahme zur cScanList hinzufügen lassen. Schaue ich mir heute Abend an.

    Ich habe mir das jetzt nochmal genauer angeschaut. Also ich befinde das es so wie ich es in eitscan_vdr266_v2.patch.zip gemacht habe als ausreichend.


    Zur Prüfung ob überhaupt noch Kanäle hinzugefügt werden habe ich noch ein paar Logausgaben hinzugefügt und die Kanalliste von sämtlichen "Schrottkanälen" befreit:


    Hier wird die Transponderliste zur Scanliste hinzugefügt

    Feb 8 11:16:28 server vdr: [11172] EIT scan: merge transponderList


    Die sind alle auf Kanal 0 und werden damit sowieso mitgescannt:

    Feb 8 11:16:28 server vdr: [11172] EIT scan: add channel 0 source S19.2E tp 212670

    [...]

    Feb 8 11:16:28 server vdr: [11172] EIT scan: add channel 0 source S19.2E tp 212611


    Im Anschluss werden nun die Transponder der Kanäle im Bereich < 100 hinzugefügt

    Feb 8 11:16:28 server vdr: [11172] EIT scan: add channel 1 source S19.2E tp 111493

    [...]

    Feb 8 11:16:28 server vdr: [11172] EIT scan: add channel 74 source S19.2E tp 111273


    Ergibt im ersten Scan 56 Einträge:

    Feb 8 11:16:28 server vdr: [11172] EIT scan: 56 scanList entries

    Feb 8 11:16:28 server vdr: [11172] EIT scan: 56 device 2 source S19.2E tp 110832

    [...]

    Feb 8 11:35:43 server vdr: [11172] EIT scan: 1 device 2 source S19.2E tp 212729


    Danach fand ich 446 neue Kanäle in der channels.conf vor.. würde sagen das passt!


    Edit: Im zweiten, manuell angestoßenen Scan wird dann auf 24 Einträge "begrenzt":

    Feb 8 12:17:42 server vdr: [12556] EIT scan: 24 scanList entries

    Feb 8 12:17:42 server vdr: [12556] EIT scan: 24 device 2 source S19.2E tp 110891

  • Neverending EPG scan?

    Zitat von kls

    Liegen auf einem solchen Transponder auch Kanäle mit höheren Nummern, so werden auch für diese Kanäle EPG-Daten gespeichert. Falls das nicht gewollt ist, müsste auch eine entsprechende Änderung in eit.c erfolgen.

    Das ist ja auch ok. Was der EITScanner liest kann er ja auch verarbeiten. Ziel ist ja nicht das EPG ab einer bestimmten Kanalnummer leer zu lassen, sondern gezielt zyklisch nur die Transponder abklappern zu lassen die zu einem Kanal in einem bestimmten Bereich gehören. Wenn man dann auf einen der Kanäle außerhalb des Bereichs schaltet müsste ja das EPG dennoch aktualisiert und eingetragen werden.

    Zitat von kls

    Neue Transponder werden hinzugefügt, wenn sie auf einem Transponder angekündigt werden, der einen Kanal mit einer Nummer kleiner Setup.EPGScanMaxChannel hat (und UpdateChannels auf "add new transponders" steht). Für PIDs gilt entsprechendes.

    Das habe ich dann zu restriktiv gemacht. Ich denke die Einträge aus der cTransponderList die vom NIT-Sectionfilter gesetzt werden muss ich mit einer Ausnahme zur cScanList hinzufügen lassen. Schaue ich mir heute Abend an.

  • Neverending EPG scan?

    Habe mal die Nacht über das Verhalten beobachtet, ist genauso wie gewünscht:


    Mit meiner Begrenzung der zu scannenden Kanäle kommt mein vdr noch auf 24 Transponder. Ich habe für diesen vdr 2 Tuner des SAT>IP-Servers reserviert und eine abgespielte Aufnahme angehalten. Dadurch werden beide Tuner frei und für den EPG Scan verwendet. Nach einem Scan gibt es erstmal die eingestellte, zweistündige Pause.


    In der Ausgabe der Tuner-Belegungen des SAT>IP-Servers sieht man das kein Tuner belegt ist:

    Code
    #1: 1 4 1 1 0 -1 0 0 1 0 0
#2: 1 4 1 1 0 -1 0 0 0 0 0
#3: 1 4 1 1 0 -1 0 0 1 0 0
#4: 1 4 1 1 0 -1 0 0 1 0 0


    Bis ich die Stop-Taste drücke und das Ausgabedevice wieder Live-Fernsehen anzeigt:

    Code
    #1: 1 4 1 1 0 -1 0 0 1 0 0
#2: 1 4 1 1 0 -1 0 0 0 0 0
#3: 1 4 1 1 0 -1 0 0 1 0 0
#4: 1 4 1 1 1 687 1 1 1 0 27848 0.000Mbps #0 0 0 B82BBBF4 10.15.10.225 45078 26 3985 56610