Beiträge von horchi

    Hi,


    ich hatte auch kurz Rückmeldung vom Support und nun seit Wochen keine Regung ... ich habe es aufgegeben, kommt mir nicht mehr ins Haus!


    Aber zu deiner Frage ja es gibt Alternativen.


    Dietmar hat das gelesen und mit prompt einen USB DVB-S2 von Haupauge zugeschickt den er noch rumliegen hatte. Treiber sind im Kernel, daher nur eine Firmware Datei von hier https://www.linuxtv.org/wiki/index.php/Pinnacle_PCTV_DVB-S2_Stick_(461e) nach /lib/firmware kopieren, Stick anschließen und schon rennt alles!


    Ein Problem gibt es (ich weiß nicht wie das bei anderen Sticks ist), wenn du einen LIRC Empfänger am TSOP verwenden möchtest funktioniert der vermutlich nicht da der GPIO Port durch die vielen Interrupts 'Durcheinander' kommt, siehe hier: https://github.com/raspberrypi/linux/issues/906


    Der Haupauge hat jedoch einen IR Empfänger eingebaut, also auch kein Problem.


    Ich wollte den Stick nicht offen rumhängen haben (Optik ;)) - hab mir daher einen FLIRC (USB IR Empfänger) zugelegt - leider nicht sooo toll wie überall zu lesen, er fungiert quasi als Tastatur daher kann man, sofern ich nichts übersehe, irexec nicht ansteuern. Den VDR bedienen geht aber ohne weiteres. Wegen irexec bin ich nun am überlegen ob ich nicht doch den IR Empfänger im DVB Stick aktiviere ;)


    Grüße Jörg

    during this:


    nothing here:

    Code
    1. root@raspi-vdr:~# netstat -s | grep buffer
    2.     0 receive buffer errors
    3.     0 send buffer errors



    Regards Jörg

    Grundsätzlich läuft die Kombination minisatip - satip Plugin in meinem Netzwerk stabil, ich verwende das satip Plugin in der selben Version auch auf anderen VDRs.

    Nur auf dem Raspi läuft es nicht, der Raspi hängt am selben Switch, keine Firewall etc, eingestellt ist es überall auf Unicast.

    zumindest der Durchsatz scheint okay zu sein:

    Code
    1. root@raspi-vdr:~# iperf -c gate
    2. ------------------------------------------------------------
    3. Client connecting to gate, TCP port 5001
    4. TCP window size: 43.8 KByte (default)
    5. ------------------------------------------------------------
    6. [ 3] local 192.168.200.145 port 32850 connected with 192.168.200.101 port 5001
    7. [ ID] Interval Transfer Bandwidth
    8. [ 3] 0.0-10.0 sec 112 MBytes 94.2 Mbits/sec


    Das lief auch schon mal auf genau diesem Raspberry prima, vor der Neuinstallation - war damals noch jessi, jetzt stretch, ob es damit zu tun hat ...

    Habe es nun mit dem streamdev statt das satip Plugin getestet. Damit läuft es :) - scheint demnach am satip Plugin oder einer Wechselwirkung in Verbindung mit rpihddevice zu liegen.


    Mit streamdev habe ich noch bei einigen privaten HD+ Kanälen Probleme mit dem Analogen Audio Ausgang des Raspberry aber das wird sich auch noch lösen lassen.

    Hi,


    ich habe minisatip laufen und verwende es zum einen zum 'versorgen' von iPad und iPhone mit der "SAT>IP" App und zum anderen für den Wohnzimmer VDR (vdr 2.4.0) mit dem satip Plugin.

    Beides funktioniert prima! Das satip Plugin sowie minisatip sind jeweils die aktuellste Version aus dem git.


    Zu meinem Problem:


    Zusätzlich habe ich noch einen VDR (auch 2.4.0) auf einem Raspberry PI 3 mit Raspbian stretch laufen (nicht dem mit dem DVB S2 Stick aus meinem anderen Post). Auch dieser wird mit dem satip Plugin betrieben. Das ganze hatte ich vo ca. 1 Jahr schon einmal am laufen, nur war damals die Version von Plugin, VDR sowie minisatip älter - welche Versionen das im einzelnen waren bekomme ich jetzt nicht mehr zusammen.


    Nun habe ich den Effekt dass die HD Bilder nicht zu erkennen sind im Log kommen diese Fehler

    Code
    1. Jun  4 10:50:54 raspi-vdr vdr: [2363] rpihddevice: [libav] Header missing
    2. Jun  4 10:50:54 raspi-vdr vdr: [2363] rpihddevice: failed to decode audio frame!
    3. Jun  4 10:50:54 raspi-vdr vdr: [2362] rpihddevice: video stream started 1280x720@50p, PAR=1/1
    4. Jun  4 10:50:54 raspi-vdr vdr: [2362] rpihddevice: display PAR=1,000, setting video render PAR=1/1
    5. Jun  4 10:50:54 raspi-vdr vdr: [2363] rpihddevice: [libav] Header missing
    6. Jun  4 10:50:54 raspi-vdr vdr: [2363] rpihddevice: failed to decode audio frame!
    7. Jun  4 10:50:57 raspi-vdr vdr: [2363] rpihddevice: [libav] Header missing
    8. Jun  4 10:50:57 raspi-vdr vdr: [2363] rpihddevice: failed to decode audio frame!
    9. Jun  4 10:50:58 raspi-vdr vdr: [2363] rpihddevice: [libav] Header missing
    10. Jun  4 10:50:58 raspi-vdr vdr: [2363] rpihddevice: failed to decode audio frame!

    komplettes log im Anhang.


    Bei SD kommt ein Bild mit vielen Artefakten und einigen Aussetzern aber kein Fehler im Log.


    Hat das jemand so am laufen? Eine Idee wo das klemmt?


    Danke und Grüße

    Jörg

    Dateien

    • log.txt

      (10,92 kB, 17 Mal heruntergeladen, zuletzt: )

    Moin,


    das Priorisieren von SD und HD steht noch auf der TODO Liste (die beim epgd im git), der Filter dass nur die angegebenen Formate bei der Suche berücksichtigt werden ist fertig, nur nicht das Priorisieren.


    Dennoch würde es in dem speziellen Fall nicht helfen, ich habe keine Idee wie man automatisch erkennen kann ob es sich um die selbe oder eine andere Sendung handelt wenn die gelieferten Daten identisch sind.

    das ist unabhängig von HD,SD davon.


    "Wiederholungen vermeiden" verhindert das mehrfache aufnehmen von Sendungen wenn diese auf verschiedenen Kanälen und oder Sendezeiten kommen,auch Jahre später wird diese dann nicht erneut aufgenommen. Es sei denn mann löscht sie Aus der Timer Historie.


    Klickt man nur Titel genügt ein gleicher Titel und es wird keine Timer angelegt, klickt man auch Kurztext muss auch dieser identisch sein. Schwierig wird es wenn man etwas aufnehmen möchte das in mehreren Folgen kommt aber immer identischen Titel und Subtitle (Kurztext) hat, dann würde man damit die Aufnahme aller weiteren Teile verhindern ... zum Beispiel bei 'Lets Dance' hier heißen alle Folgen absolut identisch da wäre es fatal "Wiederholungen vermeiden" zu aktivieren. Da kann man sich dann behelfen indem man auf Sendezeit und Kanal einschränkt.


    Hoffe das ist halbwegs verständlich ausgedrückt.

    es hat mir noch keine Ruhe gelassen habe nochmal getestet und gemessen.


    An einem anderem LNB funktioniert es auch nicht.


    Der AC Adapter ist okay und liefert angeschlossen und in Betrieb (also LNB Versorgung aktiv) 12,3V.


    Wenn LNBVOLTAGE als Enabled angezeigt wird und ein LNB angeschlossen ist kommen am F-Connector zum LNB ~0,7V an. Ist kein LNB angeschlossen kommen 6V an. In beiden Fällen wird SHORTCIRCUIT angezeigt. Und in beiden Fällen ist die LNB Versorgungsspannung zu niedrig, richtig wären ja 14V oder 18V.


    Also ist das Teil wohl kapput.


    Bin gerade drauf und dran mir wieder einen Sundtek zu bestellen, scheint ja die erprobteste und vermutlich auch einfachte Lösung zu sein. Hoffe der hält dann länger. Wie ist eure Erfahrung damit, wie lange habt ihr den am laufen? Meiner liegt zu weit über 90% Stromlos rum und wird nur aktiviert wenn ich mit dem Wohnmobil unterwegs bin und selbst dann nur selten ... halt mal für F1 oder WM/EM sonst schaue ich in Urlaub kaum TV.


    Grüße Jörg

    Wenn man Sundtek's an einem Raspberry betreib ist es immer gut einen aktiven USB hub zu benutzen.

    Ansonsten verschwinden die tuner irgendwann und man bekommt sie nicht mehr zum rennen / nur durch eine neu installation.

    Wenn man einen Aktiven usb hub benutzt passiert das dann nur noch wenn man sehr viel Pech hat.


    Aber ansonsten laufen die Sticks sehr gut

    habe es mit und ohne USB Hub versucht, immer das selbe Ergebnis. Bei mir sind die Tuner auch da und mit dem mediaclient Tool von Sundtek wird auch Empfangspegel angezeigt, nur sobald man das Signal 'nutzen' will kommt nichts und er wird ein "SHORTCIRCUIT" signalisiert, das passiert wie ich es verstehe immer dann wenn der LNB zu viel Strom zieht oder der AC Adapter nicht angeschlossen ist. Bei mir ist der Adapter angeschlossen und der LNB funktioniert mit anderem Receiver und hat bis jetzt auch immer mit dem Sundtek funktioniert.

    Da steht er eben leider nicht mehr - sonst würde er ja auch beim "Testen" des Serientimers mit einem Flag versehen sein.

    nein das Flag bezieht sich nur auf die 'timersdone' Tabelle also auf die Historie nicht auf die 'timers' Tabelle selbst.

    Wenn er nun wieder angelegt wurde war er sicher inzw. im Rahmen des erwähnten automatischen cleanups aus der timers Tabelle gelöscht worden.

    Wenn es exakt zu dem event auf dem ksnal um die Uhrzeit (also selbe eventid) noch einen timer gibt wird dafür keiner mehr angelegt, für eine spätere Wiederholung jedoch (durch das löschen aus der Historie) jedoch schon.

    Das soll endlise lösch u d Anlage Schleifen verhindern wenn ein timer z.B. wdkfn einem Konflikt gelöscht wurde.

    Also sofern er noch in der timers Tabelle im Status gelöscht steht musst du ihn auch dort löschen.

    Die werden dort erst nach zwei Tagen automatisch aufgeräumt