Beiträge von pbrb

    Danke für die Logs. Das Verhalten ansich läßt sich nun erklären.


    • 2.0.x -> stoppt den Receiver relativ früh und gibt damit Tuner "DVB 0" wieder frei
    • 2.1.0 -> stoppt den Receiver später, damit ist Tuner "DVB 0" noch blockiert und VDR nimmt den verfügbaren, aber bei Dir nicht funktionierenden Tuner "DVB 1" für den neuen Kanal her

    Das wurde schon in [osdteletext] 2.1.0 released vermutet.


    Generell wäre es hilfreich, den 2. Empfänger entweder zu deaktivieren oder (viel besser) mit Signal zu versorgen.

    Code
    Usage: vdr [OPTIONS]
    
      -D NUM,   --device=NUM   use only the given DVB device (NUM = 0, 1, 2...)
                               there may be several -D options (default: all DVB
                               devices will be used); if -D- is given, no DVB
                               devices will be used at all, independent of any
                               other -D options

    Du dürftest nämlich in das gleiche Problem laufen, wenn Du parallel eine Aufnahme startest und dann zu einem Kanal auf einem anderen Transponder wechselst. VDR würde "DVB 0" für "recording" nehmen und "DVB 1" für neues Live-TV (oder andersrum)...aber einer davon kann ja nichts empfangen.


    Bisher ist das sonst wohl keinem aufgefallen, weil wer hat im VDR schon gerne Tuner registriert, die nicht aktiv nutzbar sind...das kann auch bei 2 parallelen Aufnahmen von Kanälen auf verschiedenen Transpondern unerwartete Effekte haben (keine Timer-Kollision wird angezeigt, aber 2. Aufnahme ist leer).


    Probier mal:


    https://github.com/pbiering/vd…teletext/tree/major-2.1.x


    da gebe ich den Receiver früher frei.


    BTW: bei Tests ist aufgefallen, daß in einem 2-Tuner-System das Zapping von einem "non-live" (aka "tuned") Channel zum nächsten "non-live" noch nicht funktioniert...muß ich noch nacharbeiten.

    Ich würde da eher sagen: Schade drum. Chance verpasst einen einheitlichen Distributions-Standard umzusetzen.

    Naja....

    SQL
    UPDATE-2.2.0:- VDR now reads command line options from *.conf files in /etc/vdr/conf.d.

    D.h. VDR kann das erst seit 2.2.0, der sysconfig-Mechanismus in Fedora bzgl. VDR-Plugins dürfte schon wesentlich länger existieren...und so 1:1 kann man das auch nicht migrieren (schon gar nicht automatisch), ganz davon abgesehen, daß man da keine magischen Sachen reinbauen kann wie "autodetection" oder Benutzung von Umgebungsvariablen als Schalter.


    Weitere Diskussionen, falls notwendig, sollte man in einem neuen Thread führen.

    Debug-Level geht nicht.


    vdr --showargs



    Habe es auch mit "unsigned int m_debugmask = 4;" reinkompiliert, geht auch nicht.

    probier mal: --debugmask=0x00000004

    Und möglicherweise wird die reinkompilierte "4" überschrieben, wenn --debugmask explizit angegeben ist (aber ohne "=" wird ggf. 0 angenommen, sollte aber eine Logzeile auftauchen) - im Debug-Log-Level natürlich, d.h. vdr muß mit "-l 3" gestartet sein, sonst wird da nichts auftauchen.

    Das mit der Config-Datei keineswegs ein spezielles Setup sondern der VDR liest die selber. Sollte also eigentlich heute bei jeder Distribution so gelöst sein. Eben weil es "VDR Standard" ist. Man kann prüfen ob die Option tatsächlich beim VDR ankommt wenn man direkt auf der Maschine "vdr --showargs" aufruft.

    Also mindestens Fedora arbeitet ganz anders (immer noch).

    Code
    # vdr --showargs
    vdr: can't read arguments from directory: /etc/vdr/conf.d

    da liegen die Plugin-Configs unter /etc/sysconfig/vdr-plugins.d/ und werden von "runvdr" eingesammelt...allerdings auch recht hilfreich für Tests, denn die Configs sind ganz normale Bash-Scripts, die mit Schalter von außen beeinflußt werden können um final das jeweilige PLUGIN_OPTIONS zu füllen...

    vielleicht mußt Du alle Optionen in eine Zeile schreiben...Du kannst aber mit ps ax | grep vdr auch mal schauen, wie schlußendlich die Kommandozeile aussieht und die als User "vdr" direkt mal starten und nicht via systemd.


    Hart reinkompilieren geht natürlich auch....


    osdteletext.c / unsigned int m_debugmask = 0;


    den Default "0" anpassen...

    Kann ich --debugmask in der 50-osdteletext.conf eintragen?


    Code
    [osdteletext]
    --directory=/tmp
    --debugmask=0x00000004

    denke, ja, das daß bei Deinem Setup so funktioniert...Du wirst es im Log sehen, wenn's angenommen wurde, taucht dann so etwas auf:

    Code
    osdteletext: enable debug mask: 4 (0x04)

    und danach entsprechende zusätzlich sichtbar werdende Debug-Meldungen

    Hmm, gute Frage, woran das liegen könnte. 2.0.2 loggt leider nicht das DVB-Device mit, auf dem der Teletext-Receiver lauscht :(


    kannst Du mal 2.1.0 das osdteletext-Plugin mit folgender Debug-Mask starten:


    --debugmask 0x00000004


    das sollte alles bzgl. Channel Switches dann loggen, was so passiert in txtrecv.c / cTxtStatus::ChannelSwitch


    es reicht dann, wenn Du die osdteletext-Logzeilen postet (und "switching to channel")

    Sneak Preview auf 2.2.0 ist online zum Testen:


    https://github.com/vdr-project…text/tree/milestone-2.2.0


    Solange keine speziellen Optionen angegeben sind, sollte es sich wie 2.1.x verhalten mit den Unterschied, daß der Hintergrund-Transparenz-Wert nun (endlich) logisch ist, d.h. 0 -> keine Transparenz, 255 -> volle Transparenz und das es Tastenzuordnungen gibt, die nichts bewirken (OSD Preset + Hotkey Level) - und das man (endlich) auch für die letzte Taste im Setup-Menü eine Seitennummer zuweisen kann...


    Wenn allerdings aktiv geschalten mit:


    Code
    -k        --key-levels=NUM   Maximum amount of Hotkey levels selectable and stored
    default: 1 (which deactivate this feature)
    maximum: 9 levels
    -o        --osd-presets=NUM  Maximum amount of OSD presets selectable and stored
    default: 1 (which deactivate this feature)
    maximum: 9 presets

    und passender Belegung (Empfehlung: FastRwd: HotkeyLevel-, FastFwd: HotKeyLevel+) kann die OSD-Menüzeile bis zu 9 Ebenen bekommen, die man frei definieren kann...


    Und mit den OSD-Presets, die man dann auch mit Tasten umschalten kann, sollte jeder nun weitere (bis zu 9) umschaltbare Wunscheinstellungen finden (und nicht nur auf "HalfPage" eingeschränkt)...


    Viel Erfolg beim Testen, kann noch etliche Tage dauern, bis der 100% ausgereift ist.


    BTW: hab einen extra Thread dafür aufgemacht, damit's keinen Durcheinander gibt mit dem 2.1.0 Release ([osdteletext] 2.1.0 released)

    Hallo pbrb,


    ich habe heute die Version "Merge pull request #55 from pbiering/2.1.0.reg.5" getestet.

    Hardware ist eine Cine S2 V7A Karte von Digital Devices, es ist nur 1 Kabel angeschlossen.

    Bei Umschalten wechselt osdteletext von DVB 0 auf DVB 1 "cTxtReceiver started on DVB 1" und auf dem Bildschirm kommt die Meldung No Singal


    Hast Du die finale Version getestet? Außerdem scheint sich die Karte mit mehr als einem Tuner zu melden, der 2. funktioniert aber nicht. Beim Live-View folgt aber osdteletext eigentlich dem Tuner, den VDR einstellt...funktioniert denn das Zapping ohne osdteletext?


    BTW: das schaut nicht gut aus, bitte mal das Cache-Verzeichnis woanders hinlegen, worauf VDR vollen Zugriff hat.


    Code
    osdteletext: Error opening teletext storage subdirectory "/tmp/systemd-private-8d32327e22774fe88df076a3f9b8f1be-upower.service-ylAyyk": Keine Berechtigung

    Feature Major:

    • ChannelSwitch now supports receiving other channels from same transponder or even other transponder (aka "tuned" mode)

    Feature Minor:

    • include channel number in 'invalid channel' message

    Fixes during development:

    • catch case where in tuned mode channel switch is triggered on selected device and switch into cached mode
    • finally catch and handle proper switching from tuned to live channel by outside trigger (e.g. RCU)
    • replace all sleeps related to messages with a delay method, review/catch cases when a channel switch message should be displayed
    • various cosmetic fixes

    https://github.com/vdr-project…etext/releases/tag/v2.1.0


    https://github.com/vdr-project…gin-osdteletext/issues/11

    Sneak Preview für 2.2.0 Multi-Level Hotkey Menu:


    https://github.com/vdr-project…ne-2.2.0-HotkeyMultiLevel


    standardmäßig deaktiviert...wird erst mit -k <maxlevel> aktiv....viel Spaß beim Testen...recht nützlich imho.


    2.1.0 wird noch kosmetische Regression abbekommen...muß noch den Text anpassen, wenn ein Tuner von einem Live-Receiver anderweitig benutzt wird...danach gibt's Release...kamen bisher keine Anmerkungen/Beschwerden...


    Upcoming (dann ist aber wirklich Schluß): OSD-Presets, d.h. neben dem etwas statischen 'HalfPage' wird's ein Preset+/- geben, so daß man sich bis zu 9 OSD-Presets (Größe, Platzierung) speichern kann, die man dann durchwechseln kann von z.B. "Fullscreen" auf "rechte obere Ecke" wechseln mit einem Tastendruck...


    BTW: bei wem geht die Play-Tasten-Zuweisung? Hab nur ich das Problem hier, daß die nicht zum Plugin durchkommt...wenn das nirgends geht, dann lösch ich die raus in 2.2.0 ("Pause" hat's ja schon erwischt).

    BTW: ein Feature ist noch in hier in Arbeit: Multi-Level (aktuell 3 Levels...sollte reichen) OSD-Menü, was die Farb-Tastenbelegung umschalten kann für die vergesslichen wie mich, die sich nicht mehr erinnern, was auf Stop, FastFwd, FastRwd konfiguriert ist und auch Probleme mit der Belegung von "Play" und "Pause" bzw. "Play/Pause" haben, weil sich hier VDR mit "live-recording" vordrängelt - und somit aktuell es mehr mögliche Tastenbelegungen als Tasten gibt...


    Wollt Ihr das noch in 2.1.0 reinhaben oder soll erst mit 2.2.0 kommen?


    Danach dürfte ich alles, was ich brauche, implementiert haben.

    "offiziellen" Repo für neue Features Branches anlegst

    das habe ich ja nun gemacht und füttere den mit PRs, die mindestens meine Dev-"QA" passiert haben...


    https://github.com/vdr-project…text/tree/milestone-2.1.0


    sollte jetzt fertig sein...eben die letzte Unschönheit bei den ChannelSwitch-Meldungen rausgebaut. Wie schon erwähnt, Videotext vom Nachbar-Kanal auf dem selben Transponder kann man auch bei 1-Tuner-System nun "live" mitlesen.

    EDIT: Oh, sehe grade, es gibt ja pull request, nur keine "fremden" reviewer :)

    damit fangen die Probleme an...alles in Personalunion...und aktuell kann der Weg holprig sein, das Ziel ist mir wichtiger...(und es könnte wesentlich schlimmer sein...alles in meinem Fork, kein Branch daran, Fork-master-runs-as-it-is...oder auch nicht, und zum Schluß keine Möglichkeit mehr, das mit cherry-pick zusammenzuklauben und dann bleibt nur noch all-or-nothing.


    Den "milestone-2.1.0" Branch habe ich deswegen angelegt, damit andere nicht dauernd das Repo umschalten müssen für Beta-Tests...da gab's auch Gemecker...


    Und im Upstream-Master haben die Änderungen noch nichts zu suchen, bis 2.1.0 fertig ist, wer weiß, ggf. muß noch 2.0.x gefixt werden...ok, man könnte da einen release-maintenance-Branch erstellen und ggf. cherry-pick machen (falls der Commit kleinteilig genug war...was ich eh schon versuche so ganz nebenbei...wenn auch mit Grenzen, zuviele Abhängigkeiten/Baustellen gleichzeitig)


    PS: Hab das plugin jetzt übrigens auch drauf. Ist es "normal", dass die alte Seite "ausblendet", wenn eine neue aufgerufen wird? Oder soll osdteletext "hart" zur neuen Seite übergehen?

    Ich noch 3-4 Varianten der alten Seite im Hintergrund mit steigender Transparenz, bis sie dann weg ist. Kann aber auch ein Problem meines Ausgabeplugins sein.

    Also es wird ein OSD erzeugt und darin die Seiten final mit osd->DrawBitmap reingepinselt - da ist nichts mit Aus- und Einblenden hinterlegt. Noch nicht mal beim Kanalwechsel während Teletext-OSD aktiv ist, wird ein neues OSD erzeugt, hier mit softhddevice (und auch eHD) ist alles fix.


    Selbst der ClearPage (das aber nur noch beim Kanalwechsel aufgerufen wird), malt nur Leerzeichen mit transparenten Vordergrund und schwarzem Hintergrund.


    Hat die OSD-Implemetierung im Ausgabeplugin irgendeine seltsame Fading-Option? Verkleinere das OSD mal auf 80% und schalte den schwarzen Rahmen an und prüfe ob Du da im Rahmen auch Artefakte siehst bei Umschalten - weil der wird nur am Anfang pro OSD gemalt.


    Und OSDs werden nur bei Größenänderungen neu gemacht, sind auch im Log erwähnt, z.B.


    Code
    osdteletext: OSD area successful requested with x0=68 y0=59 width=1320 height=800 bpp=32 lF=59 rF=59 tF=59 bF=59