Posts by CyberHogo

    mal eine Frage zwischendurch:


    Seit einigen Wochen ist ja das Laden von Bildern gefixt. Ich nutze EPGD, epg2vdr und scraper2vdr mit DVB Daten (Sat) und EPG-data Abo.

    Bilder erhalte ich nun für die meisten ÖR Programme. Bei den Privaten Fehlanzeige.


    Ist das normal oder habe ich eine Konfigurationsmöglichkeit übersehen.


    Code
    root@yaVDR6:~# epgd -v
    epgd version 1.1.138-GIT from 11.03.2018

    ich habe jetzt in den Plug-in Einstellungen des softhddevice in den einzelnen Sektionen (*576i, 720p,... ) den Punkt "Inverse Filmübertragung (vdpau):" auf "ja" gesetzt und damit den Effekt der milchigen und flauen Bilder beseitigt.


    Leider habe ich keine Ahnung, was diese Einstellung macht, aber das Ergebnis ist deutlich besser.


    Sicherlich ist Trial & Error ein bewährtes Verfahren - lieber habe ich es aber, wenn ich verstehe, was ich tue.

    Bei mir treten die Probleme auch immer wieder auf. Flaues Bild und keine Brillanz.


    Beim googeln bin ich auf zwei Parameter gestoßen, die ich in diesem Zusammenhang interessant finde:


    nvidia-xconfig


    Code
    nvidia-xconfig [options]  
     
    [...]
    
          --color-space=COLORSPACE, --no-color-space              Enable or disable the "ColorSpace" X configuration option. Valid              values for "COLORSPACE" are: "RGB" and "YCbCr444".
    
    
           --color-range=COLORRANGE, --no-color-range              Sets the "ColorRange" X configuration option. Valid  values  for              "COLORRANGE" are: "Full" and "Limited".


    In diversen Beiträgen ist genau das Bildverhalten, welches auch hier beschrieben wird (flaues, gräuliches Bild) beschrieben. Offensichtlich wird der TV via HDMI angeschlossen nicht richtig erkannt und der Nvidia-Treiber steuert den TV nicht mit vollen Farbraum und Farbart an.


    Leider finde ich keine Einstellmöglichkeit, um diese fehlerhafte Einstellung zu korrigieren. Kennt sich da wer aus?

    ich würde das so sehen:

    für einen User ist das von dir beschriebene Vorgehen optimal und auch so vorgesehen. Wenn ich zum Iphone ein zweites Gerät aktiviere hilft ein Assistent per QR Code und alle Einstellungen des Iphones werden auch auf dem z.B. Ipad eingerichtet. Einfach beste User Experience.


    Bei zwei oder mehr Usern würde ich zwei Accounts und ggf. die Familienfreigabe empfehlen. So lassen sich Einstellungen u.a. wegen Datenschutz besser einrichten.

    Die gemeinsame Nutzung gekaufter Inhalte geht dann über die Familienfreigabe.


    Icloud und Itunes Account sind übrigens zweierlei. Auch hier sind je nach Szenario unterschiedliche Varianten denkbar.

    Ggf. kann so jeder User die 5GB kostenloses Cloudvolumen nutzen. Andererseit kann in der Familienfreigabe die Sichtbarkeit des Ortungsdienstes von allen gemeinsam genutzt werden.

    unter softhddevice habe ich jetzt mal das syslog näher untersucht.

    Der Spuck beginnt unmittelbar mit dem Start des Streamdev-Server-Plugins:


    Code
    Feb  6 17:12:44 yaVDR6 vdr: [2369] Streamdev: server suspend thread started (pid=1431, tid=2369, prio=high)
    Feb  6 17:12:44 yaVDR6 vdr: [2369] [softhddev]StillPicture: ts 0x7f10ef189440 21997
    Feb  6 17:12:44 yaVDR6 vdr: [2369] [softhddev]StillPicture: pes 0x7f10e80057b0 20186
     Feb  6 17:12:44 yaVDR6 vdr: [2369] [softhddev]StillPicture: ts 0x7f10ef189440 21997
    Feb  6 17:12:44 yaVDR6 vdr: [2369] [softhddev]StillPicture: pes 0x7f10e80057b0 20186
    Feb  6 17:12:44 yaVDR6 vdr: [2369] [softhddev]StillPicture: ts 0x7f10ef189440 21997
    Feb  6 17:12:44 yaVDR6 vdr: [2369] [softhddev]StillPicture: pes 0x7f10e80057b0 20186
    Feb  6 17:12:44 yaVDR6 vdr: [2369] [softhddev]StillPicture: ts 0x7f10ef189440 21997
    Feb  6 17:12:44 yaVDR6 vdr: [2369] [softhddev]StillPicture: pes 0x7f10e80057b0 20186


    Ist das jetzt ein Bug oder ein Feature? Normal aber sicher nicht.

    neue Experimente:


    Das o.g. Verhalten scheint ja vom softhddevice zu stammen. Also habe ich mal testweise auf xine als Ausgabedevice umgestellt.

    Hier sieht das dann so aus:



    Bei xinelibout als Ausgabe ist dann Ruhe. Das soll aber nicht die Lösung sein.


    Was mir zu denken gibt:


    1) Bei softhddev schein ja immer dass selbe Standbild erstellt zu werden. Was könnte hier die Ursache sein? Welcher Thread braucht sowas?


    2) Bei xine scheint es ja auch zu klemmen. Welcher Prozess könnte in beiden Devices die Ursache sein?


    Ach nochwas:


    Ich habe vor ein paar Tagen meine zwei Sky Star 2 HD DVB-PCI-Karten geben eine Cine S2 (Rev. 6.5) getauscht. Das funktionierte sofort, allerdings habe ich die Flut an Meldungen im Syslog erst später bemerkt. Ist die Cine S2 für solche Effekte bekannt? Die Karte könnte natürlich auch einen Defekt haben.

    Hallo zusammen,


    mein Syslog wird mit folgender Meldung vollgeschrieben. Leider finde ich keinen Ansatzpunkt, um das abzustellen.

    Meine Recherchen haben auch keine brauchbaren Treffer geliefert. Hat jemand einen Tipp?


    VG CyberHogo


    joachim-h: Die Timer/Suchtimer aus VDR-live werden korrekt übernommen und auch angezeigt. Das ist ja mein momentaner Workaround. Dauerhaft würde ich aber gerne alle Timer auf EPGd verwalten.


    davie2000: Das ist schon klar und das funktioniert auch. Dies ist aber eine universelle Vorgabe für alle Timer. Die Problemstellung der Überziehung von Live-Sendungen löst dies aber nicht, es sei denn ich würde bei jedem Timer den Nachlauf akzeptieren. Dies mache ich aus Effizienzgründen/Festplattenbedarf jedoch nicht.

    Hallo,


    gibt es mit EPGd die Möglichkeit, bei Suchtimern die Vor- und Nachlaufzeit beim Suchtimer einzustellen?

    Hintergrund: bei Live-Sendungen nehme ich gerne einen längeren Zeitraum. Ganz extremes Beispiel in der Vergangenheit: Bei Schlag den Raab habe ich immer 3 Stunden extra aufgenommen.


    Im VDR-live ist dies ja möglich. Daher wundere ich mich, dass dieses m.E. kleine Feature nicht in EPGd übernommen wurde.


    Oder gibt es einen Workaround?


    LG CyberHogo

    >> Voting closed: March 23, 2016, 21:19:11


    Der Hinweis kommt somit etwas spät.


    An der Umfrage haben sich 9 User beteiligt. 6 sind für den zukünftigen Support RPI ohne MVP und 3 möchten beide Geräte unterstützt sehen.


    Persönlich habe ich 5 MVPs unter Vomp im Einsatz. WAF ist hervorragend. Mein RPI3 läuft unter Kodi; hier gibt es aber noch Hürden, wie z.B. Einschalten per FB u.ä., so dass diese Lösung bei meinen Damen durchgefallen ist. Der Mehrwert des Kodi-Systems spielt dann auch keine Rolle - ist halt nicht alles rational.

    hast ja Recht ...


    Installierte Plugins:

    stimme seahawk zu; die Meldungen beginnen, nachdem ich per life-plugin auf den VDR zugreife.
    Schließe ich das Browserfernster hören die Meldung sofort auf. Möglicherweise also ein Zusammenhang mit epgsearch?


    Vieleicht kann jemand die Vermutung prüfen und reproduzieren.


    Zusatzfrage: Was hat es mit der Einstellung im VDR-Menü-Plugins-Einstellungen-epg2vdr SVDRP Interface zu tun.


    Hier gibt es die Optionen a) lokal (127.0.0.1) und b) eth0 (eigene IP des Clients). Kommt das nicht aufs gleiche raus?
    Oder hab ich die Einstellungen irgendwo verstellt.

    mmmh, wenn ich jedesmal die komplette Datenbank neu aufsetzen muss ist das Plugin möglicherweise nichts für mich.


    Nicht böse gemeint, aber es ist schon recht mühsam sich durch all die Threads zu arbeiten.
    Offensichtlich sind die älteren How To´s auch nicht mehr - so ohne weiteres -brauchbar.


    Leider habe ich momentan nicht die Zeit. Mal sehen, ob ich das Projekt nochmal relaunche.


    Wie ist dass denn mit den Paketen momentan -gibt es kein Testing mehr?
    Habe den Eindruck, dass ich diese Phase gerade im Stable habe.


    However: NEVER GIVE UP :mua

    Nach einem dist-upgrade gestern schreibt mein Client yaVDR das Syslog mit folgender Meldung zu:


    Code
    Mar 23 12:35:01 yaVDR vdr: epg2vdr: Closing mysql connection and calling mysql_thread_end(1917)
    Mar 23 12:35:01 yaVDR vdr: epg2vdr: Calling mysql_init(1881)
    Mar 23 12:35:01 yaVDR vdr: epg2vdr: Closing mysql connection and calling mysql_thread_end(1881)
    Mar 23 12:35:01 yaVDR vdr: epg2vdr: Calling mysql_init(1881)
    Mar 23 12:35:01 yaVDR vdr: epg2vdr: Closing mysql connection and calling mysql_thread_end(1881)
    Mar 23 12:35:01 yaVDR vdr: epg2vdr: Calling mysql_init(1881)
    Mar 23 12:35:01 yaVDR vdr: epg2vdr: Closing mysql connection and calling mysql_thread_end(1881)
    Mar 23 12:35:01 yaVDR vdr: epg2vdr: Calling mysql_init(1881)
    Mar 23 12:35:01 yaVDR vdr: epg2vdr: Closing mysql connection and calling mysql_thread_end(1881)
    Mar 23 12:35:01 yaVDR vdr: epg2vdr: Calling mysql_init(1881)


    Zugriff über
    mysql -u epg2vdr -pepg -Depg2vdr -h <server-IP> gelingt.


    Wie stelle ich das ab. Weshalb versucht der Client im Millisekundentakt auf den Server zuzugreifen?


    zur Info: nach dem dist-upgrade habe ich folgendes Resetting am Server vorgenommen:
    epgd-tool -del-all
    epgd-tool -new-db
    epgd-tool -new-u


    stop epgd
    start epgd (bzw. reboot)


    epgd-tool -show-stats (auf dem Server) sieht m.E. gut aus.


    Code
    root@yaVDR6:~# epgd-tool -show-stats
    +------------------------------------------+--------+--------------+----------+--------------------------+--------------------------+--------------------------+
    | version                                  | master | ip           | state    | last touch               | last download            | next download            |
    +------------------------------------------+--------+--------------+----------+--------------------------+--------------------------+--------------------------+
    | vdr 2.2.0 epg2vdr 1.1.52-GIT (2103.2017) | n      | 192.168.9.73 | attached | 23rd March 2017 12:44:11 | 23rd March 2017 12:29:26 | NULL                     |
    | vdr 2.2.0 epg2vdr 1.1.52-GIT (2103.2017) | y      | 192.168.9.71 | attached | 23rd March 2017 12:44:07 | 23rd March 2017 12:29:26 | 22nd March 2017 21:08:38 |
    | epgd 1.1.113-GIT (20.03.2017)            | -      | 192.168.9.73 | standby  | 23rd March 2017 12:43:11 | 23rd March 2017 12:30:10 | 24th March 2017 00:30:10 |
    +------------------------------------------+--------+--------------+----------+--------------------------+--------------------------+--------------------------+