Posts by Dr. Seltsam

  • [SkinNopacity] Aktuelle Probleme

    Der log level steht schon auf 3. Ich kriege nur diese Meldungen:

    Code
    Dec 01 14:10:20 CoreELEC kernel: fb: clear: osd 0
Dec 01 14:10:21 CoreELEC vdr[4242]: [4242] [softhddev]CreateOsd: left 130, top 752, level 0, using OpenGL OSD support
Dec 01 14:10:21 CoreELEC vdr[4242]: [4242] [softhddev]cOglOsd osdLeft 130 osdTop 752 screenWidth 1920 screenHeight 1080
Dec 01 14:10:22 CoreELEC kernel: fb: clear: osd 0

  • [SkinNopacity] Aktuelle Probleme

    hier erstmal meine Konfiguration:

    ein paar Werte von vdr:

    Code
    OSDSkin = nOpacity
OSDTheme = lightblue
OSDMessageTime = 1
ProgressDisplayTime = 0
ChannelInfoTime = 5

  • [SkinNopacity] Aktuelle Probleme

    Moin Kamel,


    eins stört mich schon länger: Wenn man während einer Wiedergabe die ok-Taste zum Einblenden des OSD (Fortschrittsbalken) drückt, kann man das OSD normalerweise mit einem zweiten Druck auf die ok-Taste sofort wieder schließen. Das klappt nicht immer - manchmal muss man mehrere Sekunden warten, ehe ein erneuter Druck das OSD schließt. Ich habe mit mehreren Skins und allen möglichen Werten für Ein- und Ausblendezeiten experimentiert, aber der Fehler tritt immer wieder auf. Üblicherweise reicht es, 5-10 mal die OK-Taste im Wechsel zu drücken, um ihn zu provozieren. Es tritt aber manchmal auch schon beim ersten Schließen (also zweiter Druck) auf.

    Beim Live-TV gibt es bei der Anzeige der Kanalinformation dieses Problem nach meiner Beobachtung hingegen nicht.


    Vielleicht kannst Du Dir das mal anschauen.

  • [gelöst] verzögerter VDR Start bis USB SSD verfügbar ist?

    Ich mache das ganz quick and dirty im chroot-System in der runvdr vor dem Start von vdr.

    (CoreElec startet beim Booten vdr in chroot)

    Der erste check prüft, ob CE eine externe Platte erkannt hat (device node vorhanden). Es wird unterstellt, dass das immer der Fall sein sollte.

    Der zweite check führt beim ersten Aufruf der runvdr immer dazu, dass die Platte innerhalb der chroot-Umgebung in /srv gemounted wird. Auf den erfolgreichen Abschluss des Mountens (die auf der Platte unterhalb srv vorhandenen Ordner sind dann vorhanden) wird abschließend dann nochmal gewartet.

    Wenn die Platte nicht dranhängt oder aus anderem Grund nicht eingebunden werden kann, kommt vdr nicht hoch. Dann weiss ich, wo ich suchen muss.

  • [skin flatPlus] Version 1.1.3

    Das Problem tritt schon ewig auf, obwohl ich regelmäßig den Ordner lösche und das Plugin mit git clone neu auschecke. Das klappt immer reibungslos. Nur wenn Änderungen vorliegen und ich die mit git pull übernehmen will, kommt die Meldung.

    Ich habe mal die Makefiles von skinflatplus mit vdr und anderen Plugins verglichen. Dabei fielen mir diese Unterschiede auf:


    Das minus bezieht sich auf skinflatplus und das plus auf andere Makefiles. Kann es damit zu tun haben?

  • [skin flatPlus] Version 1.1.3

    Jedesmal wenn ich ein git pull mache, kommt

    Code
    error: Your local changes to the following files would be overwritten by merge:
po/de_DE.po
po/it_IT.po
Please commit your changes or stash them before you merge.
Aborting


    Ich habe an bzw. in den den Dateien aber nie etwas geändert

  • Installation eines VDR+Plugins nativ auf CoreELEC Boxen

    Um welche Programme geht es denn, die Konfigurationsdateien in /etc haben?

    Wenn die in /usr/lib/systemd/system/ gestartet werden, könnte man eine gleichnamige systemd Service Unit in /storage/.config/system.d/ anlegen. Die wird dann vorrangig genommen. Es setzt voraus, dass das zu startende Programm einen Parameter hat, mit dem man den Pfad der Konfigurationsdateien explizit vorgeben kann. Der wird dann unter ExecStart in der service-Datei mit vorgegeben.

  • TrickSpeed - Verständnisfrage

    Für softhdodroid präferiere ich im Moment eher einen Patch in dvbplayer.c, weil das einfacher umzusetzen ist und wir dann ja eh in einem proprietären System (amlogic-eigene Treiber) unterwegs sind.


    Ich habe meinen Patch nochmal überarbeitet und auch das Play - Pause - Slow Fordward - Pause - Play - Problem integriert. Die Verwendung von GetClosestIFrame statt GetNextIFrame liefert ein deutlich besseres Ergebnis.

    rell: Ich glaube, Deinen ClearAudio-Aufruf in Mute kannst Du rausnehmen:

    Code
    void Mute(void)
{
    Debug("Mute(void)");
    SkipAudio = 1;
    ClearAudio();
}

    Der kommt ja wegen SkipAudio nie zur Ausführung:

    Code
    void ClearAudio(void)
{
    if (!SkipAudio) {
        Debug("ClearAudio()");
        CodecAudioFlushBuffers(MyAudioDecoder);
        AudioFlushBuffers();
        NewAudioStream = 1;
    }
}

  • [Gelöst] VDR mit softhddevice mit VDPAU?

    Ich orientiere mich bei sowas immer an den Paketen von seahawk1986. Das Debian-Paket mit einem Archivmanager öffnen und im Ordner DEBIAN die Datei control suchen.

    Bei softhdcuvid findet man z.B.

    Code
     Depends: libasound2t64 (>= 1.0.16), libavcodec60 (>= 7:6.0), libavfilter9 (>= 7:6.0), libavutil58 (>= 7:6.0), libc6 (>= 2.38), libfreetype6 (>= 2.2.1), libgcc-s1 (>= 3.0), libgl1, libglew2.2 (>= 2.2.0-4build1), libglu1-mesa | libglu1, libglut3.12 (>= 3.4.0), libnvidia-compute-550 (>= 550.120), libplacebo349 (>= 7.349.0+git20241013-18-9e16c86f-1yavdr0~noble), libstdc++6 (>= 11), libswresample4 (>= 7:6.0), libx11-6, libx11-xcb1 (>= 2:1.8.7), libxcb-dpms0, libxcb-icccm4 (>= 0.4.1), libxcb-screensaver0, libxcb1, vdr-abi-2.7.3-0yavdr, mesa-vulkan-drivers, spirv-tools

    Das dürfte bei softhddevice für cuvid dann auch passen, wobei softhddevice m.E. kein libplacebo braucht.

    Mir ist aber so, als wenn man für cuvid noch weitere Dateien von Nvidia braucht, die es nicht als Debian-Paket gibt.

  • [Gelöst] VDR mit softhddevice mit VDPAU?

    Das Plugin prüft beim Bauen, ob die benötigten Bibliotheken vorhanden sind. Wenn nicht, wird es ohne die entsprechende Unterstützung gebaut. In Deinem Fall scheint das Plugin nur mit VA-API-Support kompiliert zu sein.

    Gib mal auf dem System, wo Du kompilierst, auf der Konsole

    Code
    pkg-config --exists vdpau && echo 1

    ein.

    Wenn eine 1 zurückgemeldet wird, ist vdpau-Support vorhanden. Wenn nicht, musst Du die benötigten libraries nachinstallieren (sudo apt-get install libvdpau1 libvdpau-dev vdpauinfo)

  • Rückgabewert von cDevice::Poll wird ignoriert

    Quote from Dr. Seltsam

    Wenn man in softhd* in void Mute() nicht SkipAudio setzt sondern SetAudioVolume(0) nimmt, könnte es vielleicht gehen - wenn außerdem StreamFreezed beim Wechsel von Pause zu pmSlow auf 0 gesetzt wird. Auf AudioFlushBuffers muss in Mute dann wohl auch verzichtet werden.

    Das probiere ich morgen oder Freitag mal in softhdodroid.

    Habe mir das nochmal angesehen - ist leider noch komplizierter.

    StreamFreezed wird beim Aufruf von Trickspeed bereits wieder auf 0 gesetzt - das passiert also beim Wechsel von Pause zu pmSlow.

    Dass vdr während einer laufenden Zeitlupe irgendwann keine Videopakete mehr schickt, wenn SkipAudio nicht gesetzt ist, liegt also nicht an einem durch StreamFreezed ausgelösten return 0 in PlayAudio. Ich vermute, der Grund liegt hier in PlayAudio:

    Code
        // hard limit buffer full: don't overrun audio buffers on replay
    if (AudioFreeBytes() < AUDIO_MIN_BUFFER_FREE) {
        return 0;
    }

    // dont fill audio buffers too much
    if (AudioGetBufferUsedbytes() > AUDIO_MAX_BUFFERS) {
        usleep(10);
        return 0;
    }

    Es gibt noch einen weiteren Aspekt:

    Beim Drücken der Pausentaste wird über Freeze() die Funktion AudioPause() in audio.c aufgerufen. Sie bewirkt AudioPaused, was zu return 1 im AlsaThread führt. Da AudioPaused erst über AudioPlay() auf 0 gesetzt wird (was in Play() geschieht), müsste also während der laufenden Zeitlupe die ganze Zeit AudioPaused = 1 gelten. Warum es dann zu einem Überlaufen der Audio/Alsa-Buffer kommen kann, ist mir allerdings unklar.

  • Rückgabewert von cDevice::Poll wird ignoriert

    Vielleicht ist das beabsichtigt, damit der Decoder Bild und Ton intern weiter synchron halten kann. So wahrscheinlich der Fall bei av7110 (FF-SD).


    Wenn man in softhd* in void Mute() nicht SkipAudio setzt sondern SetAudioVolume(0) nimmt, könnte es vielleicht gehen - wenn außerdem StreamFreezed beim Wechsel von Pause zu pmSlow auf 0 gesetzt wird. Auf AudioFlushBuffers muss in Mute dann wohl auch verzichtet werden.

    Das probiere ich morgen oder Freitag mal in softhdodroid.

  • TrickSpeed - Verständnisfrage

    Bei mir sieht das so aus:


    GoTo verwende ich also doch, ermittle aber den Index bei einer vorherigen "Zeitlupe vorwärts" nicht mit SnapToIFrame

    Code
    bool GetIndex(int &Current, int &Total, bool SnapToIFrame = false);
// Returns the current and total frame index, optionally snapped to the
// nearest I-frame.

    Ob der zusätzliche Empty()-Aufruf bei jedem resyncAfterPause notwendig ist oder nicht auch von resyncAfterSlowForward abhängig sein sollte, muss ich mir nochmal anschauen.


    softhdodroid hat weiter keine Änderungen. void Mute() enthält

    Code
    SkipAudio = 1;
AudioFlushBuffers();


    Quote

    Meine Vermutung: softhddevice setzt durch das DeviceMute SkipAudio, was dem VDR durch die Rückgabe von size in PlayAudio() signalisiert, dass die Audiopakete angenommen worden sind. Die landen aber nicht im Ringbuffer. Bei Mute ist das schon richtig, weil die PTS ja weiterlaufen soll und dem VDR vorgetäuscht wird, dass die Audiopakete verarbeitet wurden. Bei Trickspeed ist das aber schlecht.


    Ja, das dürfte eine zutreffende Analyse sein. Was ich noch nicht sicher weiss: was ist mit StreamFreezed = 1;, das in Freeze gesetzt wird? Ich glaube das bleibt auch bei der Zeitlupe so. Das führt dann dazu, dass PlayAudio return 0 zurückgibt (wenn SkipAudio nicht gesetzt ist, was zu return size führen würde).

    Besser wäre es, wir finden einen anderen Weg den alsa-Ton stumm zu schalten. Aber das scheint wohl nur über den alsamixer zu gehen und es dürfte schwierig sein, das in C++ mit einem für alle Umgebungen passenden Code zu machen (?)


    Ohne SkipAudio und ohne AudioFlushBuffers in Mute funktioniert alles wie es soll- aber die Zeitlupe bleibt nach einiger Zeit stehen, weil vdr das Senden weiterer Videopakete einstellt. Da PlayAudio dann 0 zurückgibt, unterstellt vdr wohl, dass das device auch nicht mehr in der Lage ist, Videopakete anzunehmen. siehe auch RE: Rückgabewert von cDevice::Poll wird ignoriert


    Code
      virtual int PlayAudio(const uchar *Data, int Length, uchar Id);
       ///< Plays the given data block as audio.
       ///< Data points to exactly one complete PES packet of the given Length.
       ///< Id indicates the type of audio data this packet holds.
       ///< PlayAudio() shall process the packet either as a whole (returning
       ///< Length) or not at all (returning 0 or -1 and setting 'errno' accordingly).
       ///< Returns the number of bytes actually taken from Data, or -1
       ///< in case of an error.

  • TrickSpeed - Verständnisfrage

    Quote from rell

    Folgende Abfolge macht aber auch Probleme:

    Play->Pause->SlowForward->Pause->Play

    Habt ihr das mal getestet?

    Kann ich für softhdodroid bestätigen.

    Für play-pause-slow forward play sieht mein Fix etwas anders aus. Resync ohne GoTo sieht sauberer aus.

    Was softhddevice angeht, kann ich die Probleme nicht bestätigen, da klappt bei mir alles. Warum das bei jrie anders ist, ist noch unklar.

  • Hilfe bei backtrace Analyse erbeten

    Ich habe zwei Abstürze mit nahezu identischen backtraces, hier einer davon:


    Zeiule 148 in /usr/local/include/vdr/device.h lautet

    Code
    static cDevice *PrimaryDevice(void) { return primaryDevice; }
///< Returns the primary device.

    Dieser letzte backtrace ist aufgetreten, nachdem ich auf einem iptv-Radiokanal (Version von Zabrimus) die Pausentaste gedrückt habe. Die Live-Wiedergabe war bis dahin problemlos. Es erschien "Live-Signal wird angehalten" und dann kam der Absturz. Anliegend das log. Die Ursache ist offenbar zunächst ein emergeny exit aufgrund eines VDSB. Dann tritt während des Beendens von vdr und seiner Plugins der segfault auf. Wenn ich das richtig deute, ist das letzte bendete Plugin das radio-Plugin. Danach werden vom vdr die handler threads für die devices beendet. Dabei vermisse ich für device 5 (IPTV mit vlc2iptv, Live-Radio) sowie device 6 (darauf hat vdr die Aufnahme gestartet) Logeinträge für "section handler thread ended". Ich vermute deshalb, dass der segfault im iptv-Plugin aufgetreten ist, wie ich das an anderer Stelle früher schon mal berichtet hatte.


    In den vdr-Einstellungen steht primäres DVB device auf 5.

    0-3 dürften die 4 DVB devices ein. Wenn ich vdr beende und die Zeile mit dem primary device in der setup.conf lösche, setzt vdr nach dem Neustart wieder die 5. Laut femon ist 5 aber iptv.

  • Kodi and TT S2-6400 / FF card

    Zum Schreiben des images auf die SD-Karte nehme ich unter Linux den balena etcher.

    Das Tool von Libreelec wird für Linux wegen der Bugs schon gar nicht mehr angeboten. Ob es unter Windows weniger buggy ist weiss ich nicht.


    Ich würde noch eine amlogic-basierte Android-Box ins Spiel bringen, auf der Coreelec installiert wird. Bei vielen Boxen geht das auch auf den internen Speicher. Wenn Du die 6400 einmottest und Dir stattdessen einen linuxtauglichen USB-Empfänger anschaffst, kannst Du sogar vdr auf dem Ding laufen lassen. Boxen mit S905X3 oder S905X4 kosten mit 4GB RAM um die 50 Euro.

    Der Odroid C2 hat einen veralteten amlogic Chip, den CoreElec nicht mehr unterstützt. Sollte aber unter Libreelec noch laufen und reicht vielleicht für Kodi.


    Stichwort Amazon Prime: das geht mit Kodi nur in SD. Dann lieber gleich einen Firestick kaufen. Da sollte man Kodi als App auch drauf installieren können,