Beiträge von Okul

    Reicht es also, wenn ich in der svdrphosts.conf den Zugriff auf localhost 127.0.0.1 beschränkt lasse oder werden hier evtl. weitere Ports geöffnet, wo Angreiffer leichtes Spiel hätten?


    Wie verhindere ich zuverlässig, dass der vVDR den externen Stream abruft obwohl kein Timer gesetzt ist? Funktioniert das Out-of-the-box oder muss ich da einen Dummy-Kanal anlegen? Wegen der Fair-Use-Policy des Anbieters wäre ein permanenter Dauer-Stream wohl ein Kündigungsgrund.

    Zur Sicherheit: Ich will mich da nicht aus dem Fenster lehnen mit den geöffneten Ports, aber was spricht dagegen, einfach sowas wie ufw zu verwenden und einfach alles außer SSH zu sperren?


    Das mit dem stoppen des Streams ist so eine andere Sache. Ich hatte damit ewig Probleme, weil nach einer Aufnahme der Stream weiterlief. Zwischenzeitlich dachte ich, ich hätte das mit dem suspendoutput plugin in den Griff bekommen, aber das hat auch nicht dauerhaft/zuverlässig funktioniert.

    Am besten nimmst du wohl einen dummykanal, der immer läuft und gibst der Aufnahme eine höhere Prio. Dann sollte der nur zur Aufnahme laufen. Aber am besten ordentlich testen oO


    Einen IPTV stream kannst du aber auch einfacher mitschneiden... ;)

    Aktuelle Browser nehmen automatisch HTTPS, wenn verfügbar. Ein neuer User wird (zurecht!) nicht auf eine Seite gehen, vor der der Browser warnt. Vielleicht macht sich tatsächlich jemand die Mühe, den Fehler anzuschauen und untersucht das Zertifikat. Wenn man dann sieht, dass das seit einemJahr abgelaufen ist, ist ja schon klar, dass das Forum tot ist. Dann nimmt man doch lieber TVHeadend.

    Ein Forum, das nicht erreichbar ist, stirbt. Und ich habe Angst, dass damit auch der VDR stirbt. Ein bisschen ist das ja schon zu beobachten. Neue Nutzer nehmen TVH "wegen Konfiguration im Browser" oder was auch immer.


    Klar ist, dass eine Zersplitterung der nur noch kleinen Community in ein neues Forum nicht funktionieren wird. Wenn, dann muss das gesamte Forum auf einen anderen Server umziehen. Mit der kompletten Datenbank, also allen Nutzern und Beiträgen. Ohne Genka gehts also nicht. Vielleicht kann man ihn ja überzeugen, dass ihn eine solche Umstellung mal ein paar Stunden kosten wird, er danach allerdings keinerlei Arbeit mehr damit hat. Dafür müsste man ihn aber natürlich auch erst mal erreichen.

    An Helferlein sollte es da ja nicht mangeln. Es gibt ja offensichtlich schon genug Leute, die sich da auskennen. Ich administriere auch seit knapp 20 Jahren (omg, wie die Zeit vergeht ..) einen Server und hatte auch schonmal ein WBB. Ich kann da gerne helfen. (Würde sowas aber auch nicht alleine machen wollen, kann immer sein, dass man mal keine Lust mehr auf sowas hat).

    Nur weil es "alt" ist, muss es nicht schlecht sein. Das Samba Protokoll ist ja auch nicht so jung ;)


    Ich habe das ganze noch einfacher und sogar die Aufnahmen per VNSI statt Samba eingebunden. Nur die DVDs kommen per NFS Mount.

    Die Datenbank von KODI hatte ich auch auf dem Server, um die verschiedenen Clients abzugleichen. Das gab aber Probleme mit den Unterschiedlichen KODI-Versionen auf den Clients. Dafür würde es sich also lohnen, gleiche Rechner zu nehmen um die gleichen Versionen zu haben.


    Gerade beim Fernseh-gucken habe ich oft recht wenig Geduld und da stören mich manchmal schon die (kleinen) Wartezeiten beim Spulen/starten, etc. beim Raspberry. Wenn du eh Geld in die Hand nimmst für eine "große Glotze" mit Surround-Sound, etc dann bietet sich vielleicht auch ein NUC o.ä. an. Mit GBit Netzwerk flutscht das schon deutlich besser als beim PI und auch einige andere Dinge fühlen sich deutlich geschmeidiger an. Andererseits muss man dann auch schon dreistellig ausgeben um besser als ein Pi zu werden. (Edit: https://www.notebooksbilliger.…c+kit+nuc6cayh?nbb=45c48c kann H265 in Hardware dekodieren)

    Mit avidemux kenne ich mich nicht so aus. Wenn ich es richtig verstanden habe, musst du bei Ausgabeformat einfach "NVIDIA h264" bzw. "NVIDIA hevc" wählen.

    Du brauchst mindestens die avidemux Version 2.6.15

    Sorry fürs nicht zurückmelden. Irgendwie kam dauernd was dazwischen ;)

    das muss auch mit 'auto' funktionieren, hast du Fehlermeldungen vom epg2vdr im log?


    was liefert :

    Code
    select uuid,from_unixtime(updsp),name,version,dbapi,state,master,ip  from vdrs;


    Aber Sender EPG verarbeitet dieser VDR auch, das hat Du dem nicht per Konfig abgewöhnt?

    Code
    MariaDB [epg2vdr]> select uuid,from_unixtime(updsp),name,version,dbapi,state,master,ip  from vdrs;
    +--------------------------------------+----------------------+------+--------------------------------------------------+-------+----------+--------+--------------+
    | uuid                                 | from_unixtime(updsp) | name | version                                          | dbapi | state    | master | ip           |
    +--------------------------------------+----------------------+------+--------------------------------------------------+-------+----------+--------+--------------+
    | 5CB19DD3-194A-4C76-A1C0-15E0E5101646 | 2018-07-20 15:01:20  | NAS  | vdr 2.4.0 epg2vdr 1.1.93-GITbc845e9 (09.03.2018) |     6 | attached | Y      | 192.168.36.2 |
    | epgd                                 | 2018-07-20 14:52:27  | NAS  | epgd 1.1.135-GITb71b92e (07.03.2018)             |     6 | standby  | -      | 10.8.0.1     |
    +--------------------------------------+----------------------+------+--------------------------------------------------+-------+----------+--------+--------------+
    2 rows in set (0.00 sec)

    Das korrekte netzwerkgerät eingestellt?

    Wieso der epgd an der OpenVPN IP hängt weiß ich nicht o_O. das ist das tun0 interface. In der EPGD config steht "NetDevice = eth0". Ich habe jetzt den VPN gestoppt, dann gab es nurnoch das "lo" und "eth0" interface und dann kam


    Code
    MariaDB [epg2vdr]> select uuid,from_unixtime(updsp),name,version,dbapi,state,master,ip  from vdrs;
    +--------------------------------------+----------------------+------+--------------------------------------------------+-------+----------+--------+--------------+
    | uuid                                 | from_unixtime(updsp) | name | version                                          | dbapi | state    | master | ip           |
    +--------------------------------------+----------------------+------+--------------------------------------------------+-------+----------+--------+--------------+
    | 5CB19DD3-194A-4C76-A1C0-15E0E5101646 | 2018-07-20 15:10:16  | NAS  | vdr 2.4.0 epg2vdr 1.1.93-GITbc845e9 (09.03.2018) |     6 | attached | Y      | 192.168.36.2 |
    | epgd                                 | 2018-07-20 15:10:16  | NAS  | epgd 1.1.135-GITb71b92e (07.03.2018)             |     6 | standby  | -      | 192.168.36.2 |
    +--------------------------------------+----------------------+------+--------------------------------------------------+-------+----------+--------+--------------+
    2 rows in set (0.00 sec)




    Im live-addon sehe ich für den Kanal BR nur die Daten vom DVB. Also abgeholt werden sie. Aber irgendwie nicht an den EPGD übergeben. An dem Kanal kann ich es gut sehen, weil der bei TVSP irgendwie nicht will o_O

    Zum Thema ist ja eigentlich schon alles gesagt. Will nur der Vollständigkeit halber noch anmerken:

    Der RPI kann hardware en/decodierung (wie schon geschrieben) von Haus aus. Der Codec zum Kaufen bezieht sich nur auf MPEG-2 und VC-1, weil das extra Lizenzgebühren kostet und die RPI-macher sich das gespart haben.


    Zum Stand von Hardwarebeschleunigung von ffmpeg (am Ende verwendet fast alles unter der Haube ffmpeg, z.B. auch Avidemux):

    https://trac.ffmpeg.org/wiki/HWAccelIntro


    Für h264 bringt es aber nicht "soo" viel:

    Will a graphics card make x264 encode faster?

    For x264 specifically, probably not. x264 supports OpenCL

    Für neue Projekte will man eigentlich h265 benutzen, das ist nur halt noch relativ langsam. Braucht dafür auch nur ~40% des Speicherplatzes von h264.

    https://trac.ffmpeg.org/wiki/Encode/H.265


    Für avidemux gibts auch fertige Pakete, du musst das nicht selbst kompilieren, wenn es da Probleme gibt:

    http://ubuntuhandbook.org/inde…2-7-0-ubuntu-17-10-18-04/

    (heißt avidemux2.6, ist aber 2.7)

    na ja mit den default Einstellungen läuft es, und vor dem umstellen ist etwas lesen angeraten ;)

    Das stimmt ;)

    Die default Einstellungen hatte ich aber. Hab das jetzt von "auto" auf "on" gestellt. Momentan ist nur ein Client verbunden, der Headless auf dem gleichen Rechner läuft. Trotzdem bisher kein merge Event. Ich starte beides heute Abend mal neu und lass ihn dann mal einen Tag laufen.

    nein mit einem Standard Setup ist das nicht normal, er sollte das EPG welches über den VDR (epg2vdr Plugin) von den Sendern in die DB kommt mit dem des externen Providers mergen.


    hast du einem der VDRs erlaubt die Events in die DB zu schreiben?

    Ich habe mich damit ehrlicherweise noch nicht beschäftigt. Mir war garnicht bewusst, dass epg2vdr Einstellungen auch Auswirkungen auf das vdr->epgd Verhalten haben. Habe mich gerade durch die Readme gelesen. Sollte mich wohl noch damit beschäftigen ;) Ich vermute es liegt an der Master Einstellung, die bei mir auf 0 steht. Werde das mal testen.

    (Vielleicht wäre eine kurze Notiz in der epgd Readme nützlich, dass man auch die epg2vdr Einstellungen beachten muss.)


    Zitat

    BTW:


    Diese Zeile scheint bei dir einen Fehler zu generieren:


    Code
    if [ "$1" == "-h" ]; then

    sollte aber keine Auswirkung aus die Ausgabe des Skripts haben.

    In der Tat. Das liegt an der zsh, mit bash gehts

    Verstanden. Nach dem Bereinigen läuft momentan alles. Danke!

    (außer, dass epgd-showmerge auch nur Events vom TVSP zeigt. Dachte, das wäre normal..)


    und die Procedure ist schon beim Start nicht da, also das hier liefert kein Ergebnis?

    Code
    show procedure status where name = 'mergeepg';

    Naja, das liefert ein (1) Ergebnis in der Backup-DB. Ich habe die Datenbank mal im Betrieb kopiert, bevor ich angefangen habe zu "spielen". In der eigentlichen "Arbeits-DB". Ich habe die procedures jetzt mal aus dem Backup gelöscht. War das das Problem?

    MariaDB verwende ich auch, läuft hier ohne Probleme.

    Die Procedure wird bei Start automatisch angelegt oder, bei Änderung aktualisiert. Wenn das nicht klappt sollte es da schon eine Fehlermeldung geben. Von Hand anlegen musste ich sie noch nie. Wie sieht denn die Meldung beim epgd Start aus?

    Da kommt keine Fehlermeldung. Ganz normal ein "Calling mysql_init(3504)" dann lädt er das EPG und danach:

    Code
    epgd: Calling 'mergeepg'
    epgd: SQL-Error in 'execute(stmt_execute)' - PROCEDURE epg2vdr.mergeepg does not exist (1305) 'PROCEDURE epg2vdr.mergeepg does not exist' [call mergeepg]

    dann geht er ganz normal weiter.


    Ein restart sah so aus:

    Ich habe jetzt mittels epgd-dropall die DB gelöscht und befülle sie jetzt nochmal neu. Das sollte den schmodder dann ja loswerden...

    Hat auch nicht geholfen :(

    Habe aber ein weiteres Problem gefunden. Ich glaube ich hatte das schonmal und irgendwie gelöst, kann mich nur nicht mehr erinnern ||

    Code
    May 18 13:23:40 NAS epgd: Calling 'mergeepg'
    May 18 13:23:40 NAS epgd: SQL-Error in 'execute(stmt_execute)' - PROCEDURE epg2vdr.mergeepg does not exist (1305) 'PROCEDURE epg2vdr.mergeepg does not exist' [call mergeepg]

    In der Datenbank kann ich bestätigen, dass die Procedures und Functions nicht existieren. Wenn ich die SQL files aus dem /config Verzeichnis einspielen will, gibt es Fehler. Wenn ich die von Hand anlege beschwert sich der EPGD beim Start, dass die Funktionen schon existieren. Wenn ich sie wieder lösche, werden sie beim start nicht angelegt.


    Ich setze MariaDB ein, kann das ein Problem sein?


    [edit]

    Wie immer, kaum schickt man den Beitrag ab, fällts einem ein. Die Procedures kann ich importieren mit --delimiter="//"

    Code
    mysql -u epg2vdr -pepg --delimiter="//" epg2vdr < /etc/epgd/mergeepg.sql


    Ich habe jetzt die Funktionen gelöscht, den EPGD gestartet und während er das EPG herunterlädt, mit obigem Befehl die Funktionen erstellt. Dann kommt erfolgreich:

    Code
    May 18 13:40:33 NAS epgd: Calling 'mergeepg'
    May 18 13:41:06 NAS epgd: 'mergeepg' suceeded

    Für den Moment sieht es gut aus, aber er arbeitet ja noch ;)

    Aber wenn ich das richtig sehe, müsste ich das bei jedem Neustart machen.

    Die Meldung besagt das der VDR welcher den Timer ausführen soll die angefragte Event ID auf dem Kanal nicht findet. Der EPGD hat sie jedoch angelegt da sie in der DB vorhanden ist/war.

    Das ist schon mal eine sehr Wertvolle Information, das hat sich mir aus der Fehlermeldung so nicht erschlossen.


    Zitat

    - grundsätzlich hat dieser Kanal an dem entspr. VDR ein EPG?

    - er bezieht das EPG auch für diesen Kanal vom epgd?

    Auch sehr gute Punkte. Der VDR läuft Headless und ich habe mir da nicht so die Gedanken drüber gemacht. Die Einträge sind auf dem entsprechenden Kanal doppelt vorhanden. Einmal mit "Quelle: TVSP", einmal ohne Angabe. Ich denke da ist irgendwas schief gelaufen. Ich habe das EPG jetzt komplett neu einlesen lassen, es hat sich aber nur heute etwas geändert, nicht in den folgenden Tagen. Wenn ich später Zeit habe, werde ich den VDR stoppen, die epg.data löschen und dann neu starten.

    Insgesamt ist das auch sehr merkwürdig, habe gerade in den Logs gefunden:

    Code
    May 17 17:12:25 NAS vdr: [32047] timer 25 (1 1847-1955 VPS 'Serien~In aller Freundschaft - Die jungen Ärzte~Staffel 04~S04E15 - Drum prüfe sich…') set to event Do. 17.05.2018 19:50-19:55 'Wetter vor acht'
    May 17 17:12:25 NAS vdr: [32047] timer 26 (1 1847-1955 VPS 'Serien~In aller Freundschaft - Die jungen Ärzte~Staffel 04~S04E16 - Späte Einsicht') set to event Do. 24.05.2018 19:52-19:55 'WM-Fieber'

    Der hat die Events auf ne Stunde später geschoben? o_O


    [edit]

    Also der lädt das EPG genau so wieder aus der DB.


    Ich habe jetzt mittels epgd-dropall die DB gelöscht und befülle sie jetzt nochmal neu. Das sollte den schmodder dann ja loswerden...

    Was führt eigentlich dazu, dass ein Event nicht mehr gefunden wird? Das betrifft nur einzelne Kanäle, z.B. ARD. Das Event wird plötzlich nicht mehr gefunden, der Timer wird gelöscht. Wenn ich den Timer dann aus der Auftragshistorie lösche, wird er wieder angelegt. Einen Tag später verschwindet der Timer wieder, weil Event nicht gefunden. Wenn ich nicht dauernd hinterher bin, wirds halt nicht aufgenommen :/


    Was mich wundert ist, dass die EventID immer die gleiche ist, das scheint sich also nicht zu ändern. Eine Wiederholung des gleichen Serientimers auf einem anderen Kanal (MDR) läuft völlig ohne Probleme.



    - Kann ich einstellen, dass wenn ein Event nicht gefunden wird, dass ich zwar eine Mail bekomme, der Timer aber trotzdem erst mal weiter läuft?

    - Wenn das Event wieder da ist, sollte der Timer von alleine wieder angelegt werden.

    - Ich habe nicht die neueste Version aus dem GIT, da die damals nicht lief (siehe einige Beiträge weiter oben). Habe seit dem keine neuen Updateversuche unternommen, könnte ich natürlich mal wieder. (Hat sich in der Hinsicht was geändert?)

    Bin mit meiner PicoPSU auch sehr zufrieden. Du musst beachten, dass Netzteile meistens nur bei >80% Last ihren vollen Wirkungsgrad erreichen und drunter oft komische Sachen machen (Fiepen, unterirdischer Wirkungsgrad, Hitze, etc). Man sollte das also nicht zu dolle überdimensionieren.