Posts by Joe_D

    Das Ziel ist es, Treibern mitzuteilen, was gerade nicht benutzt wird, um Strom, Bandbreite, ... zu sparen.

    Bei vtuner-ng hatte ich am Anfang auch nur ein Freigeben nach Close drin - wurde aber nur beim Beenden vom vdr geschlossen. Danach ein Idle-Timeout nach 30 Sekunden wenn keine PID mehr angefordert wird. Leider hat der vdr nach einem Scan die PIDs nicht abgemeldet. Dann hab' ich zusätzlich eingebaut das nach 60 Sekunden auch freigeben wird wenn nur Section-PIDs angefordert wurden. Das hat sich leider mit VPS-Aufnahmen gebissen, seitdem ist der Timeout konfigurierbar auf die VPS-Vorlaufzeit. Puhhh...


    Mit dem Close-Patch könnte ich nun den Idle-Timeout wieder rausnehmen, bzw. standardmäßig bei 0 "totlegen".

    Wenn es wichtig ist, das das Frontend seites VDR nicht geschlossen wird - damit kein anderes Programm das DVB-Device "klauen" kann, würde es für vtuner-ng ausreichen nach einem Scan sämtliche PIDs abzumelden. Das könnte ich dann auswerten...

    Do You have the newer device version with one USB port?

    I have only one USB port

    Best option to troubleshoot is connect to UART port and attach console to it to see all messages or interact with U-Boot.

    I use the box in my production environment. I'll have to see when I can find time to open it...

    To know if You booted from it, check available applications (double TAB), there should be minisatip and some others.

    I formatted the stick and put your file on it and rebootet... But that didn't work..


    fdisk shows this about the stick:

    Code
    Disk /dev/sda: 64 MB, 64487424 bytes
    255 heads, 63 sectors/track, 7 cylinders
    Units = cylinders of 16065 * 512 = 8225280 bytes
    
       Device Boot      Start         End      Blocks  Id System
    /dev/sda1   *           1           8       62896   e Win95 FAT16 (LBA)
    Partition 1 has different physical/logical endings:
         phys=(6, 254, 63) logical=(7, 212, 13)
    
    Command (m for help):

    Rename the firmware to "Elgato_UAB_Boot_Image" and place it on a FAT32 formatted USB stick. Plug it in to USB port and reboot. The device should boot firmware from USB stick.

    Tried today and it didn't worked:

    Code
    scsi 2:0:0:0: Direct-Access     LEXAR    DIGITAL FILM     /W1. PQ: 0 ANSI: 2
    sd 2:0:0:0: Attached scsi generic sg0 type 0
    usb-storage: device scan complete
    sd 2:0:0:0: [sda] 125952 512-byte hardware sectors: (64.4 MB/61.5 MiB)
    sd 2:0:0:0: [sda] Write Protect is off
    sd 2:0:0:0: [sda] Mode Sense: 0d 00 00 00
    sd 2:0:0:0: [sda] Assuming drive cache: write through
    sd 2:0:0:0: [sda] Assuming drive cache: write through
    sda: sda1
    sd 2:0:0:0: [sda] Attached SCSI removable disk


    I'm able to mount it:

    Code
    /dev/sda1 on /usb type vfat (rw,relatime,fmask=0022,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1)


    It's not the only file on the usb-stick:

    Code
    [ARCLinux]$ d /usb
    total 32418
    drwxrwxrwx    3 root         16384 Jan  1  1970 .
    drwxr-xr-x   19 root             0 Jan  1  1970 ..
    -rwxr-xr-x    1 root      15769239 May 22  2024 Elgato_UAB_Boot_Image
    drwxrwxrwx    2 root          2048 Mar 27  2022 System Volume Information
    -rwxr-xr-x    1 root        220049 Jun 21  2009 grldr
    -rwxr-xr-x    1 root           155 Jun 22  2010 menu.lst
    -rwxr-xr-x    1 root      17170432 Nov 30  2012 microcore-current.iso

    Joe_D

    Kennst du den Patch:

    Würde sagen das ist eine schlechte Idee. MAX_DELSYS gibt im Kernel vor wie groß fe->ops.delsys ist. Da nun einfach VTUNER_MAX_DELSYS zu verwenden funktioniert nur wenn das immer kleiner gleich MAX_DELSYS ist. Leider ist MAX_DELSYS nur in den Sourcen definiert, d.h. im Userspace nicht. Und VTUNER_MAX_DELSYS kann ich reinschreiben was ich will, z.B. 356. Müsste dann aber an der Stelle ordentlich krachen!

    Im git ist eine aktualisierte Version mit folgenden Änderungen:


    • tune id hinzugefügt, d.h. bei Wechsel auf eine neue Frequenz wird der Umschaltvorgang eine id mitgegeben die dann in den TS-Paketen hineincodiert werden können (optional). Das satip Programm macht das nun. Beabsichtigte Wirkung: Zuordnung der TS-Pakete. Wenn zum Zeitpunkt des Umschaltvorgangs TS-Pakete mit id 3 gesendet werden und die neue id ist 4, dann werden nun alle noch gesendeten TS-Pakete mit id 3 verworfen und erst wieder die Pakete mit id 4 durchgelassen.
    • timeout Parameter hinzugefügt, nach dieser Zeit werden Frontends freigegeben wenn nur Section-Pids übertragen werden. Der EIT-Scan belegt ein Frontend 20 Sekunden, bei VPS könnte das ein Problem sein/werden - eventuell muss dann diese Funktion stillgelegt werden...
    • Patch von durchflieger eingebaut um satip als user starten zu können

    Ich teste das auch mal bei mir!

    Funktioniert nun mit Timeout 180 bei VpsMargin 120:


    Kann man das eventuell per Modul-Parameter konfigurierbar machen? Dann könnte man vor dem Laden des Moduls in die setup.conf des VDR schauen und den Wert dementsprechend anpassen.

    Ja ich baue das als Parameter ein

    Um 14:32 wird auf den Sender getuned weil der Timer den vps margin erreicht.

    Kurz danach wechseln alle Tuner am exip auf unbelegt!!!

    Ja, ich weiß nun auch warum: Wenn nur Section-Pids angefragt werden gebe ich die Tuner nach 60 Sekunden frei. Der Scan selbst braucht nur 20 Sekunden, an VPS selbst habe ich nicht gedacht :whistling:

    Leider ist die VpsMargin Einstellung im VDR unbegrenzt, da kann man auch 9999999 Sekunden Vorlauf eingeben...


    Die Frage ist nun was ist ein guter Standard-Timeout Wert?

    jemand eine Idee bzw. das gleiche Problem

    Komisch. Ich sehe gar keinen Compilerfehler in Form von z.B. nicht vorhandenem Symbol oder sowas ähnliches...

    Wenn vtuner-ng das nicht kann, dann funktioniert damit kein VPS.

    vtuner-ng "kann nichts" sondern empfängt Kommandos von /dev/dvb/frontendX und leitet diese einfach an /dev/vtunercX weiter. Dort muss ein Programm die Kommandos auswerten und (im besten Fall) einen TS-Stream in /dev/vtunercX hineinschreiben. Das "beigelegte" satip-Programm filtert nix, der TS-Stream kann lesend über /dev/vtunercX "mitgehört" werden falls man der Meinung ist da würde was fehlen.

    Der vdr startet keine Aufnahme bei Timern bei denen vps zugeschaltet ist!

    Ich teste das auch mal bei mir!

    Also wenn man dem virtuellen DVB Device eine IPTV Playlist (M3u oder so) als Quelle mitgeben könnte und man dann über die Channels.conf diese umschalten kann... wäre das vielleicht eine gute Alternative zum IPTV Plugin...

    Gibt es eine C-Library für M3U die das Format liest und eventuell einen Stream liefert?
    Das Parsen von dem M3U "Format" ist ja Körperverletzung ...


    Hab' gerade selber was gefunden: https://github.com/selsta/hlsdl

    So ganz blicke ich da auch noch nicht durch.

    Ist im Endeffekt ziemlich einfach: vtuner-ng emuliert bis zu 8 DVB-Karten auf einem Linuxrechner.

    Das was am vtuner-ng-Adapter rauskommen soll muss über die Control-Devices /dev/vtunercX "reingeschoben" werden.

    Als Anwendung für vtuner-ng gibt es das satip-Programm. Das nimmt hierzu Kontakt mit einem satip-Server auf und schiebt den TS-Stream in das vtunercX-Device.


    Es ist aber auch möglich andere Quellen zu verwenden. In ein paar Tagen bekomme ich eine IP-Cam, da werde ich dann mal versuchen den Livestream als "Programm" über vtuner-ng an den vdr zu schicken...


    Möchte man einen SatIP Stream mit einem Programm nutzen, das nur auf Gerätedateien zugreifen kann ist vtuner-ng sinnvoll da es im Gegensatz zum SatIP Plugin die Streams vom SatIP Server über Gerätedateien in /dev/dvb/... abbildet. Das SatIP Plugin dagegen ist nur "VDR intern" nutzbar.


    Habe ich das so richtig verstanden ?

    Richtig, vtuner-ng kann von jedem Programm verwendet werden das /dev/dvb-Adapter ansprechen kann - also auch z.B. tvheadend...

    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:

    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

    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.

    Ich denke, streamdev handelt das anders

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


    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