Posts by panik105

    Hallo,


    es sieht so aus, das gestern ca. 11:30 über tvm Daten reingekommen sind, die den epgd dann nachfolgend beim Movie-Scrapen zum Absturz bringen.


    Ich habe zwischenzeitlich mittels epgd-dropall alles außer der User-Konfig gelöscht, /var/cache/epgd komplett geleert, damit alles neu geladen wird und nochmal geprüft, dass ich bzgl. epgd und tvm-plugin auf aktuellem Stand bin -> kein Erfolg!


    Hier ein Logauszug:


    Code
    Jun 26 13:52:09 mvdr3 epgd: 7532 of 7532 series episodes scraped in 1036 s, downloaded 923.328 MB
    Jun 26 13:52:09 mvdr3 epgd: Scraping new movies
    Jun 26 13:52:09 mvdr3 epgd: 428 new movies to scrap in db
    Jun 26 13:52:14 mvdr3 epgd: movie 10 / 428 scraped...continuing scraping
    Jun 26 13:52:16 mvdr3 kernel: [225768.953580] epgd[938174]: segfault at 0 ip 00007fe95dcc5846 sp 00007fffc53c3e68 error 4 in libc-2.31.so[7fe95dc4d000+14b000]
    Jun 26 13:52:16 mvdr3 kernel: [225768.953593] Code: 0f 1f 40 00 66 0f ef c0 66 0f ef c9 66 0f ef d2 66 0f ef db 48 89 f8 48 89 f9 48 81 e1 ff 0f 00 00 48 81 f9 cf 0f 00 00 77 6a <f3> 0f 6f 20 66 0f 74 e0 66 0f d7 d4 85 d2 74 04 0f bc c2 c3 48 83
    Jun 26 13:52:16 mvdr3 systemd[1]: Started Process Core Dump (PID 949756/UID 0).
    Jun 26 13:52:18 mvdr3 systemd-coredump[949757]: Process 938174 (epgd) of user 0 dumped core.#012#012Stack trace of thread 938174:#012#0  0x00007fe95dcc5846 __GI___strlen_sse2 (libc.so.6 + 0x9d846)#012#1  0x00007fe95df21855 _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSEPKc (libstdc++.so.6 + 0x134855)#012#2  0x000055fa81ac7d87 _ZN13cMovieDbMovie9ParseJSONEv (epgd + 0xa2d87)#012#3  0x000055fa81ac6fdc _ZN15cMovieDBScraper9ReadMovieEi (epgd + 0xa1fdc)#012#4  0x000055fa81ac65ef _ZN15cMovieDBScraper5ScrapENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_ (epgd + 0xa15ef)#012#5  0x000055fa81ab217a _ZN15cMovieDBManager12ProcessMovieE12sMovieResult (epgd + 0x8d17a)#012#6  0x000055fa81a954ef _ZN5cEpgd14scrapNewEventsEv (epgd + 0x704ef)#012#7  0x000055fa81a92938 _ZN5cEpgd4loopEv (epgd + 0x6d938)#012#8  0x000055fa81a88de7 main (epgd + 0x63de7)#012#9  0x00007fe95dc4ed0a __libc_start_main (libc.so.6 + 0x26d0a)#012#10 0x000055fa81a8854a _start (epgd + 0x6354a)
    Jun 26 13:52:18 mvdr3 systemd[1]: epgd.service: Main process exited, code=dumped, status=11/SEGV

    Tritt das evtl. bei noch jemandem auf?

    Da epgd ständig neu gestartet wird, ist mir das auch 24h durch die Lappen gegangen..

    Als Erweiterung zu meinem Beitrag Raspberry Pi 4B Unterstützung :


    Es gibt inzwischen eine Beta-Version von osmc, die auf Debian bullseye basiert, und auch armhf-vdr-Pakete bei e-tobi für bullseye (d.h. auch vdr 2.6 statt 2.4).

    Nachdem ich erfolgreich geupdatet habe, gibt es folgende Änderungen:


    - auf meinem Server liegen jetzt Pakete für buster und bullseye

    - einige Pakete wurden aktualisiert (z.B. neuerer Stand softhddevice-drm

    - für bullseye liegen dort auch Pakete für epgd (das ist dann aber amd64..)

    - es ist jetzt ein richtiges Repo statt nur Paketen

    - einzubinden z.B. mittels deb [arch=armhf signed-by=/usr/share/keyrings/nopanik.asc] https://www.nopanik.org/vdr bullseye base

    - der Public Key liegt unter https://www.nopanik.org/vdr/Release.asc


    Tschuess..,

    Michael

    Ich kann da keinen signifikanten Unterschied feststellen! Vielleicht bin ich zu anspruchslos oder alt (mit schlechteren Augen) oder wahrscheinlich beides :)

    Wir haben hier gerade nochmal eine explizite Versuchsreihe gestartet mit dem selben Ergebnis (und andere Augen sind besser als meine..).


    Hattest du den Effekt nur mit dem vdr oder auch sonst (z.B. kodi) und führst ihn somit auf die HW zurück? Ich kann mit Kodi nämlich auch keinen wesentlichen Unterschied feststellen.


    Generell muss ich zu meinem Setup aber sagen, dass ich hier MagentaTV mit dem iptv-plugin nutze, d.h. ÖR in 720p und Private sogar nur in SD.


    Ich bin mit dem Umstieg bislang sehr zufrieden, da der vdr und insbesondere skindesigner mit shady-skin einerseits viel flüssiger und andererseits auch stabiler laufen!

    Hallo,


    ich betreibe seit langem auf einem RaspberryPi2 eine vdr-Installation auf Basis der debian-basierten Kodi-Distribution osmc mit den Paketen von e-tobi.

    Mittels einiger Skripte à la systemctl stop mediacenter, systemctl restart vdr (und umgekehrt) schalte ich zwischen kodi und vdr hin und her.


    Die seit August aktuelle osmc-Version basiert noch auf buster, hat aber Kodi 19 Matrix, einen aktuellen Kernel und bietet erstmals ein Image für

    RaspberryPi4 (64Bit Kernel mit 32Bit Userland). Das passt gut, da die vdr-Pakete von e-tobi auch für buster sind (neuere gibt es nicht) und

    ebenfalls 32Bit (armhf)


    Da hier schon seit Jahren :) ein RaspberryPi4 auf seinen Kodi- und vdr-Einsatz wartet, will ich umsteigen; wg. Raspi4 und auch wg. des von

    Kodi 19 verwendeten Grafik-Stacks läuft aber leider kein rpihddevice mehr, weshalb ich diesen Thread seit einiger Zeit verfolge und mich mit

    softhddevice-drm beschäftige.

    Ich habe zunächst mittels einer 2. Installation (Raspbian und das Skript von nafets227) getestet, möchte aber eigentlich gerne mein Setup

    mit schnellem Wechsel zwischen Kodi und vdr auf einer Installation wieder haben.


    Deshalb habe ich (auf Basis des Skripts von nafets227) Debian-Pakete für softhddevice-drm und die passende ffmpeg-Version gebaut.

    Jetzt läuft es so wie ich mir das vorstelle!

    Da evtl. jemand Interesse daran haben könnte, liegen diese nun unter https://www.nopanik.org/vdr.


    Anmerkungen:

    - dort liegen aktuell nur die Pakete, das ist kein einbindbares apt-Repository

    - tw. nicht debian-konform (wg. ABI-Break müsste es eigentlich libavfilter8 bzw. libavfilter-extra8 heißen!)

    - dort liegen auch noch einige andere im Laufe der letzten Jahre entstandene Plugins, die es bei e-tobi nicht gibt

    - zum Testen reicht es m.E. aus, folgende Pakete zu installieren:

    vdr-plugin-softhddevice-drm

    libavcodec-extra58

    libavutil56

    libswresample3

    libavfilter-extra7

    libavformat58

    libswscale5

    libpostproc55

    libzimg2

    Der Inhalt von /etc/vdr/plugins/iptv/vlcinput/Das Erste IP.conf muss

    URL="https://mcdn.daserste.de/daserste/de/master.m3u8"

    lauten.

    Außerdem wird in vielen anderen Beispielen hinter A=... die Nummer vom Anfang wiederholt (in deinem Beispiel also A=10080.

    Hallo,


    nette Sache.


    Ich habe allerdings noch Folgendes gefunden:

    File "/home/osmc/.kodi/addons/plugin.video.vdr.recordings/resources/lib/vdrrecordingfolder.py", line 89, in initializeInfo

    self.framerate = int(info_line[2:])

    ValueError: invalid literal for int() with base 10: '13.88888889\n'


    Das war eine Radio-Aufnahme, in deren info-Datei F 13.88888889 stand.

    Ich habe leider keine weitere und kann auch keine mehr erzeugen, weiss also nicht, ob das normal ist.

    Nachdem ich 14 reingeschrieben habe, gehts jetzt - im Vdr laesst sie sich auch weiterhin abspielen.


    Was nicht funktioniert: Bildvorschau wie hier in diversen Screenshots gesehen.

    Sollte das gehen?

    Muss Kodi dafür Schreibzugriff auf die Recordings-Ordner haben?


    Tschuess..

    Michael

    Hallo,


    ich habe hier vdr 2.2.0 (aus dem Repository von e-tobi), sowie epgd 1.1.42, epg2vdr 1.1.16 und scraper2vdr 1.0.1 (alle selbst gebaut).
    Immer mal wieder beim Beenden von Aufnahmen bekomme ich einen segfault in libvdr-epg2vdr.so.
    Nachdem ich es nicht geschafft habe, eine Reproduzierbarkeit herzustellen und auch hier im Forum nichts dazu gefunden habe, habe ich es jetzt endlich mal geschafft einen Backtrace zu erstellen.



    Ich habe in diesem konkreten Fall auf 2 Kanälen Direkt-Aufnahmen gestartet (ohne Timer) und dann im Hauptmenü versucht, eine dieser Aufnahmen zu beenden.
    Ich hatte denselben Fehler aber auch schon bei Timer-Aufnahmen, bei nur einer Aufnahme, usw..


    Ich habe versucht, mir den Segfault anhand des Codes zu erklären - ohne Ergebnis :)
    Wäre schön, wenn jemand was dazu sagen könnte.


    Tschuess..
    Michael

    Hallo,


    alle Ports auf 1GBit. Wenige Sekunden waren 2-3; das passt dann nicht zu den IGPMv3-Problemen.


    Als ich es heute nachstellen wollte zwecks syslog -> jetzt läuft alles ?!


    Es ist mir nicht bewusst, was geändert zu haben. Inzwischen habe ich auf -d 4 erhöht und kann z.B. 3x HD-Aufnahme und 1x HD live. Auch auf dem 2. Rechner parallel mit vdr und /oder vlc geht.


    Sorry for the noise - ich werde es im Auge behalten, da Probleme, die ohne Änderung verschwinden auch ohne Änderung wiederkommen..


    An was ich mich noch erinnere: als ich gestern auf einem IPTV-Kanal Infos mittels Femon-Plugin anzeigen wollte, waren auf der 2. und 3. Seite nur "---" zu sehen.
    Ich dachte, dass das dann halt nicht geht bei IPTV, heute funktioniert es aber problemlos. Evtl. ein Hinweis darauf, dass gestern irgendein grundlegendes Problem bestand.


    Tschuess..
    Michael

    Hallo,


    ich halte diesen Thread wg. der Skizze oben für gut zu meiner Frage passend und reaktiviere ihn deshalb mal.


    Ich teste gerade T-Entertain mit vdr und dem iptv-Plugin.


    Mit der channels.conf von fnu läuft das soweit sehr gut, danke dafür.
    Allerdings habe ich Probleme mit dem gleichzeitigen Aufnehmen und live gucken (Parameter des Plugins: -d 2, später evtl. mehr).
    Ich habe mich durch diverse Threads gewühlt und glaube, das mit dem "IGMPV3-Problem" soweit verstanden zu haben, es passt nur
    nicht zu meiner Realität :)


    Verwendete Systeme
    Debian jessie mit vdr von e-tobi, d.h. vdr 2.2.0, iptv-plugin 2.2.1
    Linux 4.5.0 bzw. 4.6.0 (von debian-backports)
    Telekom 100 Mbit-Anschluss
    FritzBox 7490 mit FritzOS 6.60


    Jetzt das Phänomen:
    2 Rechner (gleiche Softwarestände (s.o. sowie VLC und passendes Browserplugin)).
    Ich teste im VLC mit der Senderliste von grinch.itg-em.de oder per Browserplugin mit den Links, die in der Fritzbox unter LiveTV angeboten werden sowie im vdr mit der genannten channels.conf.


    Sobald ich auf dem selben Rechner 2 iptv-Devices nutze oder 2 Vdrs auf den beiden Rechnern mit iptv nutze oder auf einem Rechner vdr mit iptv und auf dem anderen Vlc nutze, sieht es so aus als hätte ich das "IGMPV3-Problem": nach wenigen Sekunden bricht auf beiden Seiten das Bild weg.


    Aber:
    - Wenn ich auf beiden Rechnern Vlc verwende, geht es
    - Beide Rechner hängen ohne Switch direkt an der FritzBox


    Es wäre schön, wenn sich jemand darauf einen Reim machen könnte.


    Tschuess..
    Michael

    Hi,


    ich betreibe hier vdr (2.2.0-4~etobi) mit softhddevice (0.6.0+git20150324)
    unter Debian Jessie mit vdr-experimental-Repository von e-tobi.


    Dort gibt es seitdem ffmpeg wieder in sid Einzug hielt (vor einigen Monaten)
    einen Jessie-Backport von ffmpeg, seinen libs und Kodi.


    Mit ffmpeg 2.5.4 lief das problemlos, später kamen 2.7.2 (2x) und dann 2.8.1.
    Mit diesen hatte ich jeweils den Effekt, das beim Umschalten auf verschiedene
    Sender häufig das Bild schwarz blieb, der Ton aber funktionierte. Nach
    weiteren Umschaltvorgängen klappte es dann aber immer irgendwann.
    Ich habe dann jeweils wieder 2.5.4 installiert und die Pakete auf hold gesetzt.


    Nachdem nun sowohl ffmpeg als auch Kodi "offiziell" in jessie-backports zu
    finden sind (http://balintreczey.hu/blog/ff…rived-to-jessie-backports),
    habe ich einen weiteren Versuch gestartet -> ohne Änderung, d.h. prinzipiell
    läuft alles (nur kodi-pvr-vdr-vnsi muss man noch von e-tobi holen), der Effekt
    beim Umschalten ist aber unverändert.


    Bei der Recherche zu diesem Beitrag bin ich dann über http://www.vdr-portal.de/board…an%C3%A4le-mit-ffmpeg-2-7
    gestolpert, habe mir vdr-plugin-softhddevice mit den beschriebenen Änderungen und
    neu gebaut und es läuft jetzt einwandfrei.


    Ich werde im Blog von e-tobi darum bitten, dass der Fix übernommen wird.


    Tschuess..
    Michael

    Hallo,


    ich versuche seit einiger Zeit, das Plugin ans Laufen zu bringen.
    Eigentlich sollen vdr und plexmediaserver auf dem selben Rechner
    (debian jessie i386) laufen, aber das scheint nicht zu funktionieren.
    Jedenfalls wird vom Plugin kein plexmediaserver gefunden.
    Testhalber habe ich mir einen vdr auf meinem Desktop installiert
    (debian jessie amd64), von dort geht es.


    Was ich gemacht habe:
    libpoco aus debian/experimental gebaut (inkl. in diesem Thread erwähnten
    Patch für aktuelle libpcre).
    vdr-plugin-plex (0.1.0 und vorher bereits einige ältere Stände direkt aus dem git)
    plexmediaserver 0.9.11.7.803-87d0708-debian von shell.ninthgate.se
    Prinzipiell läuft plex (inkl. Zugriff per Browser, Plex-Android-App, upnp und Plexbmc).
    Ausserdem habe ich in plex erfolgreich VDR.bundle und plex-vdr-live.bundle
    eingebunden.


    Evtl. hat das Problem auch hiermit zu tun:
    Wenn ich vdr mit aktiviertem plex-plugin vor dem plexmediaserver starte, dann
    scheint sich dieser nicht richtig zu initialisieren, z.B. klappt dann
    der Zugriff mit der Android-App nicht. Ich denke, da kommen sich irgendwelche
    Ports in die Quere. Gefunden wird der (lokale) Plex-Server aber auch dann nicht.


    Übrigens ist nach Restart von plex und vdr in der umgekehrten Reihenfolge
    ein Android-Reboot fällig, damit der Server wieder gefunden wird - irgendwie
    stehe ich mit diesem ganzen Auto-Discovery-Zeug auf Kriegsfuss und hätte gerne
    explizite IP-Adress- und -Port-Angaben konfigurierbar :)


    Tschuess..
    Michael