Beiträge von iNOB

    Sodelle, mit einer GT1030 bekomme ich mit NVidia 396.54, ffmpeg 3.4.4 bzw. ffmpeg 4.0.2 und Cuda 9.1 SDK auf SD, HD und HD+ ein prima Bild. Entäuschend siehts dann auf UHD (z.B. FashionTV, UHD1 usw.) aus. Ton ist da, aber das Bild ruckelt bzw. stockt alle paar Sekunden. Die CPU Last sieht nicht viel anders aus, wie auf den HD oder HD+ Kanälen. Daran kann es also nicht liegen. Gibt es da noch Optimierungsmöglichkeiten meinerseits, eventuell bei ffmpeg?

    Beim Compilieren von markad (command) gegen ffmpeg 4.0.2 kommen diverse Errors, da "AV_CODEC_ID_MPEG2VIDEO_XVMC" komplett aus der API rausgeflogen ist. Gibt es für markad einen Patch der das behebt? Oder macht es eher Sinn, besser wieder auf den ffmpeg 3.4er Zweig zu wechseln?

    Hab hier mehrere virtuelle Instanzen mit Let'sEncrypt Cert (nginx als auch apache) laufen und muss nichts updaten, dass geht automatisch. Da gibts genug Howtos für. Das dauert auch keine Stunden, sondern wenns hochkommt vielleicht eine halbe Stunde um das sicher einzurichten. Kommt halt auf die Umgebung an, wo der Krempel läuft.

    Das letzte große Aufbäumen im Forum war der Wechsel von SD zu HD (FF-Karte zu softhddevice). Danach kam noch der skindesigner und epgd/epghttpd als herausragende Entwicklungen. Zum TV schauen und recorden reicht der aktuelle Stand vollkommen aus. UHD ist "nice to have", wird aber bis jetzt noch nicht dringend benötigt, da wenig bis kein Content vorhanden ist und nicht jeder ein entsprechendes Endgerät hat.


    So gesehen wundert es mich nicht, dass Weterentwicklung etwas einschläft. Das war aber auch schon zur FF-Karten-Zeit so. Also immer locker bleiben ;)

    Hab das System und das Aufzeichnungsverzeichnis auf einer 4TB Platte, Datenklo spielen zwei 8TB Platten, die sich kurz nach dem Start zur Ruhe legen. Obwohl bei mir zusätzlich das scraper2vdr-plugin läuft, läßt sich das Menü ohne Verzögerung öffnen. Mounte ich während der Laufzeit die beiden Datenklos ins Aufnahmeverzeichnis, kann ich auch keine Verzögerung feststellen. Außer beim "Reinmappen", da brauchts halt etwas, bis er den Datenbestand durchgenudelt hat. Ab da sehe ich keinen Unterschied.


    PS: Das scraper2vdr-plugin benutzt bei mir eine externe Datenbank ...

    Spricht eigentlich irgend etwas gegen FreeNAS in einer VM?

    Lass es. War auch meine erste Überlegung, als ich meinen Proxmox Server zusammengestöpselt habe. Zum damaligen Zeitpunkt war ZFS allerdings unter FreeNAS noch nicht so weit. Hab dann Samba4 als Fileserver und einen ADDC (Active Directory Domain Contoller) in je einen LXC-Container gepackt. Das Datengrab mit ZFS formatiert und nach Samba als virtuelles Laufwerk reingereicht. Rennt 1A und ist von der Geschwindigtkeit her nahe am Maximum. Die Benutzer- und Gruppenrechte vergebe ich über den ADDC.


    Selbstverständlich kann man FreeNAS in eine VM (kein LXC) packen. Problem ist der Datenzugriff. In jedem Proxmox bezogenen Forum wird davon abgeraten. Da geht nur entweder oder. Kommt halt drauf an, was man mit der Möhre machen will.

    Nach einem Reboot kommt dann das:

    Hmm... es wird nicht besser. Bin mir sicher, dass ich die Tabelle irgendwann mal "gealtert" habe, weshalb ich den SQL-Fehler auch nicht nachvollziehen kann. Wenn ich in die mysql DB schaue ist die Tabelle "vdrs" vorhanden.