Posts by uwe67

frank0304

Funktioniert das auch mit der komplett freien Variante https://github.com/jellyfin/jellyfin

Grüße

Uwe

Ich hab hier als VDR-Server ein ASRock J4105 mit 4fach CineS2. Das Board selbst braucht 3-4 Watt, max 10).

Die CineS2 (wegen den LNBs) braucht viel mehr als das gesamte Board mit den HDs.

Aus Stromspargründen ist es auch gleich ein NAS-Server .

Gruß

Future Wunsch 1:

könnte man den LevelSelector https://github.com/clappr/clappr-level-selector-plugin oder besser https://github.com/LA1TV/clappr-quality-selection-plugin einbauen? Und als Parameter <videobitrate> dem ffmpeg übergeben, z.B. so:

ffmpeg -loglevel warning -f mpegts -analyzeduration 1.2M -probesize 5M ... -c:a aac -ac 2 -b:v <videobitrate> -maxrate <videobitrate> -bufsize <videobitrate>

Träum... Future Wunsch 2:

Im Fullscreenmodus: per Maus/Touchscreen eine Kanalauswahlliste ala https://github.com/irongomme/clappr-channels mit jeweils dem Senderlogo.

Das wäre für ein Android-Tablet ideal.

Tolle Sache!

Mit VAAPI geht CPU Auslastung von 125% auf 17% runter!

Auf meinem 10 Watt System mit openSUSE Tumbleweed, ffmpeg 4.1, IntelCeleron J4105 CPU, bei 1.50GHz, Kanal "ZDF HD", habe ich folgende Werte probiert:

CPU transcoding:

bei allen live.StreamVideoOpt...

ffmpeg -loglevel warning -f mpegts -analyzeduration 1.2M -probesize 5M -i <input> -map 0:v -map 0:a:0 -c:v libx264 -preset ultrafast -qmin 18 -qmax 30 -g 25 -r 25 -c:a aac -ac 2

VAAPI transcoding:

bei allen live.StreamVideoOpt...

ffmpeg -loglevel warning -f mpegts -analyzeduration 1.2M -probesize 5M -hwaccel vaapi -hwaccel_output_format vaapi -i <input> -map 0:v -map 0:a:0 -vf 'deinterlace_vaapi=rate=field:auto=1,scale_vaapi=w=1280:h=720' -c:v h264_vaapi -preset slow -qmin 18 -qmax 30 -g 25 -r 25 -c:a aac -ac 2 -b:v 2M -maxrate 2M -bufsize 1.8M

Für maximale Bildqualität Parameter "-b:v 2M -maxrate 2M -bufsize 1.8M" weglassen.

Und das tollste auf einem betagten Android-Handy über VPN Mobilfunk (Upload 736kbit/s) im Chrome Browser geht es ohne zu murren mit diesen Einstellungen (Video Bitrate auf 300kbit/s):

ffmpeg -loglevel warning -f mpegts -analyzeduration 1.2M -probesize 5M -hwaccel vaapi -hwaccel_output_format vaapi -i <input> -map 0:v -map 0:a:0 -vf 'deinterlace_vaapi=rate=field:auto=1,scale_vaapi=w=640:h=360' -c:v h264_vaapi -preset slow -qmin 18 -qmax 30 -g 25 -r 25 -c:a aac -ac 2 -b:v 0.3M -maxrate 0.3M -bufsize 0.3M

Hallo Klaus,

ich Blindfisch, ich habs, der Fehler war schon im ersten Post #7 von mir schon ersichtlich:

Ich dachte SVDRPHostName wäre der Servername.

Auf dem Client so einstellen und es geht:

Gruß

kls wrote:

Hast du auch auf dem Server SVDRPPeering = 1 gesetzt?

Ja,

mit 1 und 0 getestet.

Hallo Klaus,

immer noch kein erfolg, test Server nur mit SATIP.

Wenn ich den Client starte kommt auf dem Server wie erwartet:

nur der vdr sieht nicht den broadcast.

Gruß

Hallo Klaus,

habe gerade mal die Verbindung mit socat getestet, broadcast geht hin zum server2.

Hallo Klaus,

die Datei channels.conf kopiere ich vor start des Clients vom Server. Ich habe gerade es nochmal ausprobiert, ohne Erfolg.

Anbei Logs .

Gruß Uwe

Hallo,

auch ich hab das Problem: "Fehler beim Ansprechen des fernen Timers 0@server2".

Ein neuer Server und ein neuer Client im Netzwerk mit vdr 2.4.0 und den Patches von ftp://ftp.tvdr.de/vdr/Developer/Patches/vdr-2.4.

Getestet mit streamdev und einem Ausgabe Plugin xineliboutput oder softhddevice.

Soviel wie ich verstanden habe, habe ich in Client setup.conf folgendes eingetragen damit Remotetimer aktiv wird:

und auf der Server setup.conf:

stehen.

Ein svdrpsend -d server2 LSTT funktioniert auf dem Client.

Wie soll es eingestellt werden?

Gruß Uwe

Da ich immer noch das xineliboutput mit seinen hervorragenden Medienplayer benutze habe ich mal das 3D OSD auch ins xineliboutput eingebaut.
Anbei diff für xineliboutput 2.0.1 und 3dcontrol_0.0.7.

Vielleicht kann es einer gebrauchen.

Gruß
Uwe

Hiermit gebe ich den Sourcecode und die Hardware als Open Source frei. Wer möchte kann das Projekt weitermachen.

Gruß Uwe

PS:Keine yaUsbIr Restbestände mehr vorhanden.

Die Firmware V3.5 ist noch in Bau.

jasminj wrote:

Geht das nur in S3 (Suspend to RAM), oder auch in S5 (PowerOff)?

Sowohl S3 und S5 (S1 S2 S4 auch) sollten funktionieren wenn das Mainboard/Bios dies an dem USB-Port unterstützt. Ganz einfach zu testen mit einer USB-Maus oder USB-Tastatur, und versuchen den Rechner über die Maus oder Tastatur zu wecken. Wenn dies funktioniert so wird es auch mit dem yaUsbIR 3.5 funktionieren.

Gruß Uwe

Fux wrote:

Hallo Uwe,
weil ich eben in Deiner Signatur "yaUsbIR V3.5" gelesen habe: kommt da demnächst hardwaretechnisch was neues oder bezieht sich die Revision auf die Software?

Grüße
Fux

da kommt eine neue Firmwaresoftware, u.a.:
- USB Remote WakeUp (PC über USB aufwachen lassen wenn der PC USB Anschluss dies unterstützt)
- IR-Code der Powertaste beim Einschalten nicht weiterleiten (IR-Codes für die ersten 5 Sekunden nach einschalten nicht weiterleiten)
- IR-Code länger als 64 Impulse über USB anlernen lassen
- Auf- und Abschwellen der Helligkeit der Power-LED (ST4) wenn der Rechner aus ist (must have...), das blöde Blinken der PC-Power-LED ging mir auf den sa...
- ...

Gruß Uwe

louis wrote:

ich hab mir mal ein Ticket eröffnet, damit ich den Patch bei der nächsten Version nicht vergesse

Habe den RemoteTimer- Patch für nOpacity so abgeändert, dass er jetzt im Hintergrund alle 30 Sekunden den Remotetimerrefesh ausführt.

Lasse das jetzt durch meine Frau testen...

Gruß Uwe

louis wrote:

ich hab mir mal ein Ticket eröffnet, damit ich den Patch bei der nächsten Version nicht vergesse

Mach den Patch noch nicht rein, der ist noch suboptimal. Wenn ein RemoteTimer beendet ist wird er noch nicht aus der Timerliste rechts im MainMenu rausgeschmissen. Vielleicht ist es besser das ganze doch über einen asynchronen Aufruf mit Remotetimerrefresh zu machen.

Gruß Uwe

louis wrote:

Aber das Lesen der Remotertimer generell ist doch noch genauso schnell...oder habe ich da was übersehen?

Hallo Louis,

der bremsende Teil ist "pRemoteTimers->Service("RemoteTimers::RefreshTimers-v1.0", &errorMsg);". Dieser wird nun nur beim ersten Aufruf von cGlobalSortedTimers() ausgeführt. Der Service("RemoteTimers::RefreshTimers-v1.0", &errorMsg)-Aufruf wird beim editieren der Timer sowieso immer wieder aufgerufen (mit dem Bremseffekt natürlich), somit ist der Timer auf der Clientseite immer aktuell.

Nachteil: Wenn auf Serverseite oder über ein 2. Client die Timer geändert wird bekommt der 1. Client hier nix mit, wird aber aktualisiert sobald der Timer auf Client 1 wieder angezeigt/editiert werden.

Gruß Uwe

louis wrote:

Mal schauen ob ich das mal umsetze, ich benutze keine Remotetimer und brauche das nicht. Patches sind aber auch willkommen

Ich habe mal schnell ein Patch für nOpacity gemacht, damit die Daten vom Remotetimerplugin richtig angezeigt werden.
Was jetzt mit Patch funktioniert:
- der rote oder graue runde Bobbel wird entsprechend gesetzt
- gelbes REC in der Kanalanzeige
- rotes REC in der Kanalanzeige
- Beschleunigtes lesen der Servertimer (kein Cache)

Was nicht geht (Remotetimers bietet da kein Service):
- Statusanzeige in der Kanalanzeige welche Empfangskarte im Server gerade was aufnimmt

Patch bitte mal ausführlich testen.

Gruß Uwe

louis wrote:

- Added information about running recordings in DisplayChannel

Kann man dass noch "RemoteTimers" fähig machen?

Also bei mir wird da nichts angezeigt, da ja alles auf dem Server aufgenommen wird. Auch der rote runde REC-Nobbel wird nicht aktualisiert (wird nicht rot). Die Timerauflistung im MainMenu hingegen funktioniert vollständig mit RemoteTimers.

Was mir noch aufgefallen ist: Wenn das Plugin RemoteTimers aktiv ist und je mehr Timer programmiert sind desto langsamer wird das MainMenu nach "Menu"-Tastendruck angezeigt .

Gruß Uwe

Mein Freund,

der hier macht so was professionell http://www.censys.de/

Gruß Uwe