Posts by Dr. Seltsam

Nach meiner Kenntnis läuft die Umstellung auf vollständige Unterstützung durch den mainline-Kernel mehr als schleppend, so dass vermutlich vieles nicht oder nicht richtig funktionieren wird. Im Zweifel fehlt sogar die Hardwaredekodierung.
Es wird schon seinen Grund haben, dass die CoreElec-Entwickler soviel Zeit in die offenbar schwierige Umstellung auf den amlogic-Kernel 5.15 investieren. Das würde kein vernünftiger Mensch machen, wenn eine genauso gute mainline-Unterstützung schon am Horizont zu sehen wäre.

Also wird der Klinkenstecker in die Buchse gesteckt, die als "Digital Audio Out (Optical)" bezeichnet ist?? Das macht doch gar keinen Sinn. Ein optisches Signal kann nie aus einer Klinkenbuchse kommen, die überträgt nur elektrische Signale.

Was macht man denn, wenn man ein Gerät mit einer coaxialen (elektrischen) SPDIF-Verbindung anschließen will? Soll man dann den Digitalton mittels dieses Adapters aus einem Anschluss holen, der eigentlich schon ein elektrisches Signal bereitstellt, um dann am Toslink-Ausgang einen Konverter optisch auf elektrisch anzuschließen??

Was ich mir jetzt höchstens vorstellen könnte ist, dass da aus der Klinkenbuchse kein Consumer-SPDIF kommt, sondern ein Signal im Professional-Format, auch als AES/EBU bekannt. Pegel und Impedanzen unterscheiden sich. SPDIF hat 0,5V und 75 Ohm, bei ARS/EBU ist es 5V und 110 Ohm. Vielleicht braucht der Samsung-Adapter das hochpegelige Signal?

Hast Du ein Multimeter?

Für welche Richtung ist der Adapter? Es scheint sich um BN39-01154M zu handeln. Dessen Beschreibung lautet "Optical to 3.5mm Adapter TV Gender Cable". Für mich sieht das aber eher so aus, als wenn der Adapter eine Toslink-Buchse hätte - dann wäre der 3,5mm-Klinkenstecker zum Anschluss an den TV und es handelt sich um einen Adapter "3,5 mm to Optical".

Ein elektrisches SPDIF-Signal ist zweipolig, deshalb hätte ein zweipoliger Klinkenstecker gereicht. Vermutlich überträgt der dritte Kontakt des Klinkensteckers die Speisespannung für die Wandler-Elektronik, die offenbar hochkompakt im Gehäuse der Toslink-Buchse integriert ist. Die Frage ist nun, auf welchem Kontakt liegt die Spannung und wo das SPDIF-Signal.

Ich würde an Deiner Stelle erstmal einen 3,5mm Klinke auf 2x Cinch/RCA-Stecker wie https://www.amazon.de/Stereo-Anlagen…l/dp/B09Z6YW1TS anschließen und dann mit einem Multimeter ausmessen, ob und auf welchem der beiden Kanäle eine Spannung übertragen wird. Für den anderen Kanal (auf dem das elektrische SPDIF-Signal anliegt) kannst Du dann einen handelsüblichen SPDIF Koax auf optisch Adapter wie https://www.amazon.de/Koaxial-Optisc…r/dp/B000LB827Q nehmen. Wenn meine Theorie mit der Speisespannung stimmt, könntest Du die mit etwas Basteln evtl. sogar vom TV nehmen und auf das separate Steckernetzteil verzichten. Würde ich aber lieber nicht machen. Wir wissen ja nicht, wieviel Milliampere der TV dafür bereitstellt. Möglicherweise ist die Stromaufnahme des externen Adapters zu hoch.

Während einer laufenden Wiedergabe einer Aufzeichnung komme ich an die EPG-Infos zur Aufzeichnung mit der Info-Taste - sofern eine solche auf der Fernbedienung vorhanden ist und dafür konfiguriert wurde. Ansonsten muss ich mich im OSD über das Aufzeichnungsmenü bis zu der Aufnahme durchhangeln. Praktisch wäre es, wenn man die Infos über eine Farbtaste direkt aufrufen könnte. Bei Wiedergabe sind die Farbtasten aber alle schon mit anderen Funktionen belegt, wobei Blau fast das gleiche macht wie die Zurück-Taste

Quote

Stoppt die Wiedergabe und speichert die aktuelle Position, damit die Wiedergabe später an diesem Punkt fortgesetzt werden kann.

Einziger Unterschied ist, dass man mit Blau direkt im Live TV ist, während man nach der Zurück-Taste im Aufzeichnungsmenü ist. Dieses kann dann aber mit der Menü-Taste sofort geschlossen werden. Meist würde auch ein zweiter Druck auf die Zurück-Taste reichen, sofern man nicht zu viele Unterordner hat.

Nun gut, wahrscheinlich haben sich viele an die Blau-Taste zum Beenden einer Wiedergabe gewöhnt und würden eine Umwidmung in "EPG Info zur laufenden Wiedergabe" ablehnen.

Was gäbe es noch für Möglichkeiten? Könnte man bei Druck auf die OK-Taste (Einblendung Fortschrittsbalken) die EPG-Info als Sonderfunktion auf eine Farbtaste (abweichend von ihrer Funktion während Wiedergabe ohne Fortschrittsbalken) legen? Oder könnte man im OSD Hauptmenü bei Wiedergabe zusätzlich zu Grün (Audio) und Blau (Beenden) noch eine weitere Farbtaste für die EPG-Info aufnehmen? Dann wäre man zumindest mit nur 2 Klicks am Ziel.

Brschreib mal Dein setup näher. Die. AVM-Box hat m.E. nur einen Quad-Tuner für DVB-C und kann kein DVB-T2. Woher stammt also der DVB-T2 Tuner, auf den vdr zugreifen will? Und warum sollte vdr das machen, wenn es sich um einen DVB-C-Kanal handelt?

Die einzige Situation, die ich mir vorstellen kann: Du hast neben dem satip-device noch ein DVB device wie z.B. Hauppauge WinTV dualHD. Da diese sowohl C als auch T2 empfangen können, musst Du die Nutzung z.B. mit dem delsys-Plugin auf eine Empfangsart beschränken. Das hat dann aber nichts mit der 6490 zu tun!

Quote from rell

Bist du sicher, dass VDR GetVideoSize() aufruft und nicht ein anderes Plugin, z.B. ein Skin?

Du hast Recht. Skinnopacity macht den Aufruf, weil es wissen muss, in welchem Seitenverhältnis es das das Videobild in seinem OSD-Fenster darstellen soll. Den Aufruf habe ich bei replay wohl deshalb nicht gesehen, weil ich da nie die Menütaste gedruckt habe und so nie ein OSD-Aufruf kam.

Bezüglich des base class-Aufrufes: siehe z.B. dvbsddevice:

void cDvbSdFfDevice::GetVideoSize(int &Width, int &Height, double &VideoAspect)
{
  if (fd_video >= 0) {
     video_size_t vs;
     if (ioctl(fd_video, VIDEO_GET_SIZE, &vs) == 0) {
        Width = vs.w;
        Height = vs.h;
        switch (vs.aspect_ratio) {
          default:
          case VIDEO_FORMAT_4_3:   VideoAspect =  4.0 / 3.0; break;
          case VIDEO_FORMAT_16_9:  VideoAspect = 16.0 / 9.0; break;
          case VIDEO_FORMAT_221_1: VideoAspect =       2.21; break;
          }
        return;
        }
     else
        LOG_ERROR;
     }
  cDevice::GetVideoSize(Width, Height, VideoAspect);
}

dvbhddevice hat die gleiche letzte Zeile in der Funktion. Bei rpihddevice und sämtlichen softhd*-Plugins fehlt es.

Wenn ich es richtig verstehe, soll es Aufgabe des Ausgabeplugins sein, das Seitenverhältnis zu ermitteln um

1. ein richtiges Seitenverhältnis bei der Skalierung auf die Bildschirmgröße vorzunehmen (also z.B. 720x576 nicht-anamorphes Vollbild nicht bildschirmfüllend auf 1920x1080 auszugeben, sondern Balken links und rechts einzufügen)
2. ggf. anamorph ausgestrahlte Sendungen (das dürfte nur bei mpeg2 720x576 eine Rolle spielen) richtig zu behandeln. (Die Größe ist immer 720x576, aber bei 16:9 wird das Bild seitlich gestaucht und muss dann entweder mit eingefügten Balken dargestellt werden oder - wenn der Bildschirm 16:9 ist - in die Breite gezogen werden. Denkbar wäre auch, nur ein Widescreen-flag zu setzen und die richtige Darstellung dem TV zu überlassen - das setzt aber die Hardware-Fähigkeit voraus, WSS-bits zu übertragen.)
3. auf Anforderung über GetVideoSize einem Plugin die Größe und das Seitenverhältnis mitzuteilen.

Diese Beschreibungen aus device.h verwirren mich nun, weil der Unterschied nicht deutlich wird:

  virtual void SetVideoDisplayFormat(eVideoDisplayFormat VideoDisplayFormat);
         ///< Sets the video display format to the given one (only useful
         ///< if this device has an MPEG decoder).
         ///< A derived class must first call the base class function!
         ///< NOTE: this is only for SD devices. HD devices shall implement their
         ///< own setup menu with the necessary parameters for controlling output.
  virtual void SetVideoFormat(bool VideoFormat16_9);
         ///< Sets the output video format to either 16:9 or 4:3 (only useful
         ///< if this device has an MPEG decoder).
         ///< NOTE: this is only for SD devices. HD devices shall implement their
         ///< own setup menu with the necessary parameters for controlling output.

Worum es mir aber eigentlich geht:

Das Seitenverhältnis kann sich während einer laufenden Sendung ändern. Das sieht man bei den Privatsendern Super RTL, RTL up und RTL Nitro in SD öfters, da diese zwischendurch immer mal wieder alte Shows zeigen, die damals noch in 4:3 produziert wurden. Es reicht also nicht, Größe und Seitenverhältnis einmalig beim Playmode-Wechsel zu ermitteln, sondern die Videodaten müssen ständig geprüft werden. Das Seitenverhältnis kann zumindest bei mpeg2 recht einfach aus dem sequence header ermittelt werden. Bei h264 ist das offenbar nur aufwändiger über die SPS Daten möglich. Für h264 und HEVC kann man in der Regel zwar unterstellen, dass das Seitenverhältnis immer 16:9 ist. aus. RTL Nitro strahlt in SD z.B. 960x540 mit 16:9-Kennung aus. Nun habe ich aber eine h264-Aufnahme in 720x576 mit 4:3-Kennung...

Es scheint, als wenn vdr Breite, Höhe und Seitenverhältnis in remux.c (z.B. void cH264Parser::ParseSequenceParameterSet) bereits selbst ermittelt. Deshalb frage ich mich, ob es nicht der richtige Weg wäre, wenn vdr dem Ausgabeplugin diese Daten mit übermitteln würde, statt es jedem Ausgabeplugin zu überlassen, die Angaben aus den angelieferten Daten wieder mühsam selbst zu ermitteln.

So wie ich device.h

  virtual void GetVideoSize(int &Width, int &Height, double &VideoAspect);
         ///< Returns the Width, Height and VideoAspect ratio of the currently
         ///< displayed video material. Width and Height are given in pixel
         ///< (e.g. 720x576) and VideoAspect is e.g. 1.33333 for a 4:3 broadcast,
         ///< or 1.77778 for 16:9.
         ///< The default implementation returns 0 for Width and Height
         ///< and 1.0 for VideoAspect.

und die Ankündigungen in der HISTORY

- The new function cDevice::GetVideoSize() returns the size and aspect ratio
  of the video material currently displayed. This function is used to determine
  the proper size of the OSD. Plugin authors should implement this function in
  classes derived from cDevice, if they are able to replay video.

- The name of the function cDevice::GetVideoSize() wasn't very well chosen
  for its purpose of defining the optimum size of the OSD for the current
  output device. Therefore a new function named cDevice::GetOsdSize() has
  been introduced (suggested by Rolf Ahrenberg). Plugin authors should
  implement this function in classes derived from cDevice, if they are able
  to replay video. cDevice::GetVideoSize() still exists and should return the
  actual size of the video material that is currently replayed. Note that
  because of the many possible aspect ratios for video material, the type
  of the Aspect parameter of GetVideoSize() has been changed to 'double',
  and the Aspect parameter in both functions is named differently, because
  it returns different values (suggested by Reinhard Nissl).

verstehe, soll diese Funktion auch für Wiedergabe von Aufzeichnungen genutzt werden. Ich stelle aber fest, dass zwar bei jedem Kanalwechsel im Ausgabeplugin ein Aufruf von GetVideoSize durch vdr erfolgt, aber nicht wenn man eine Aufzeichnung abspielt. Ist das so gewollt, oder könnte ein Konstruktionsfehler im Ausgabeplugin vorliegen?

Ich sehe, dass manche Ausgabeplugins am Ende dieser Funktion cDevice::GetVideoSize(Width, Height, VideoAspect); aufrufen. Ist das erforderlich? Ein entsprechender Hinweis fehlt in device.h und in der PLUGINS-html wird GetVideoSize gar nicht erwähnt.

kls, kannst Du für Erleuchtung sorgen?

Quote from Paulaner

Momentan verwende ich das letzte CoreElec-NE-Image vom vergangenen Freitag :
   VDR-CoreELEC-Amlogic-ne.aarch64-21.2-Omega-2025-03-22.3.tar

Das ist übrigens auch kein image, sondern ein update-Paket, das Du in den .update Ordner einer lauffähigen CE-Installation packst und das dann beim Booten das System aktualisiert. Damit kriegst Du aber weder einen neuen Kernel, noch einen neuen device tree und auch kein neues Linux-System. Komplette images stellt Zabrimus nur in größeren Abständen bereit. Von daher die Frage - wie weit zurück liegt denn das letzte image, dass Du installiert hast?

Quote from vdr_rossi

Das Thema Dynamite bitte woanders diskutieren.

Warum erwähnst Du es dann in #70 eingangs?
Es dürfte aber keinen Zusammenhang der Fehlermeldung mit dynamite geben, denn letzteres verwaltet nur input devices. Die Meldung kommt aus der Audioverarbeitung und sagt, dass der Rückgabewert eines ffmpeg-Befehls unerwartet < 0 ist. Passt die ffmepg-Version in VDR*ELEC zu der, die rells Ausgabeplugin verwendet?

Zum Thema Festlegen eines devices auf eine bestimmte Empfangsart (nur bei Mischbetrieb notwendig): Dafür braucht man eigentlich kein dynamite. Dafür gibt es das delsys-Plugin. Allerdings setzt das voraus, dass man die Konfiguration statisch festlegt und einkompiliert. Da müsste sich eigentlich mal jemand ransetzen und es per OSD-setup konfigurierbar machen...

Quote from wirbel

Ich hab ja heute schon bestellt

Einzelteile, einen selbst konfigurierten Komplettrechner oder einen Fertig-PC von der Stange?

Ich denke es ist in erster Linie die Frage, ob man Zeit und Lust zum Zusammenbau hat. Bei der Teileauswahl würde ich mich immer an einem Bauvorschlag der c‘t orientieren. Oft muss man die Teile dann aber bei mehreren Händlern bestellen, weil keiner alle hat. Treibt die Versandkosten hoch und man muss warten, bis der letzte geliefert hat. Wenn mir dann ein Händler einen fertig zusammengebauten Bauvorschlag anbietet, würde ich heute wahrscheinlich lieber etwas mehr ausgeben und diesen Weg gehen.
Bei mir steht der Rechner im Wohnzimmer und muss super leise sein. Sowas kriege ich allenfalls bei Spezialisten als Komplett-PC, und so pingelig wie ich bin, würde ich wahrscheinlich selbst damit nicht zufrieden sein. Komnt hinzu, dass ich kein Windows brauche und seit fast 20 Jahren mit Linux und Xfce bestens zurechtkomme. Das schränkt die Wahl der Komplettrechner weiter ein.

Ich kenne diesen Effekt sonst, wenn für die Nvidia-Karte in pavucontrol die Lautstärke bei aktiviertem passthrough nicht exakt auf Mittelstellung ist. Und es muss ein 2.0-Profil konfiguriert sein, i.d.R. "Digital Stereo (HDMI)"

Ich habe die Datei direkt im nano-Editor per ssh geöffnet. Genauso wurde sie ursprünglich auch angelegt. Ich werde mal eine neue SD-Karte vorbereiten.

Quote from Dr. Seltsam

Moin Kamel,

eins stört mich schon länger: Wenn man während einer Wiedergabe die ok-Taste zum Einblenden des OSD (Fortschrittsbalken) drückt, kann man das OSD normalerweise mit einem zweiten Druck auf die ok-Taste sofort wieder schließen. Das klappt nicht immer - manchmal muss man mehrere Sekunden warten, ehe ein erneuter Druck das OSD schließt. Ich habe mit mehreren Skins und allen möglichen Werten für Ein- und Ausblendezeiten experimentiert, aber der Fehler tritt immer wieder auf. Üblicherweise reicht es, 5-10 mal die OK-Taste im Wechsel zu drücken, um ihn zu provozieren. Es tritt aber manchmal auch schon beim ersten Schließen (also zweiter Druck) auf.

Beim Live-TV gibt es bei der Anzeige der Kanalinformation dieses Problem nach meiner Beobachtung hingegen nicht.

Vielleicht kannst Du Dir das mal anschauen.

Hallo kamel5 ,

zur Info: Das Problem lag in softhdodroid und wurde dort gefixt!

Gruß

Dr. Seltsam

Bei der Suche nach einem Problem in Kodi habe ich auf dem Raspi meiner Eltern schließlich festgestellt, dass in einer Python-Scriptdatei plötzlich Müll stand. Etliche Zeichen waren falsch, an einigen Stellen waren Zeichen zu sehen, wie sie bei Verwendung falscher Zeichensätze entstehen können. Die Scriptdatei war vom Dateidatum her aber nie angefasst worden.
Ich kenne es von sterbenden Datenträgern, dass Dateinamen plötzlich falsch angezeigt werden. Falscher Dateiinhalt ist mir aber neu. Kann das auch ein Symptom einer sterbenden SD-Karte sein? Es geht um die STORAGE-Partition bei LibreElec - ich glaube die ist FAT32-formatiert. Der Raspi ist dauerhaft am Strom.

Ich würde nicht zuviel Zeit in den NUC investieren. Die Intel-Bildausgabe ist alles andere als trivial und nach meiner Erfahrung weder sonderlich stabil noch in der Bildqualität überzeugend. Es hat schon seinen Grund, dass einer der aktivsten Entwickler bei der Intel-Ausgabe entnervt auf amlogic-ARM-Boxen umgestiegen ist. Für einen vollwertigen VDR mit super Bildqualität braucht es kaum mehr als 50,- Euro für eine S905X3 Box. Dazu eine per USB angeschlossene externe SSD. Wakeup ist möglich. Wer etwas mehr Power beim Schneiden haben will, nimmt einen Odroid N2+.

PayTV ist eine rechtliche Grauzone, Diskussionen dazu sind in diesem Forum unerwünscht. Selbst wenn man ein legales Abo hat, verstößt man zumindest gegen Nutzungsbedingungen.

Danke für die Info.

es hätten eigentlich nur 2 Zeilen entfernt werden müssen, weil FE_SCALE_NOT_AVAILABLE fälschlich als error behandelt wurde. Das habe ich im Forum auch alles genau beschrieben. Dafür wollte der Maintainer dann einen Pullrequest haben, und da wurde es mir dann zu blöd.

Quote from Paulaner

Das ist egal, ich habe beides getestet, also direkt Start zum VDR und auch mein normaler Weg direkt Start zu KODI.
In beiden Fällen muss ich erst den Wechsel VDR -> KODI -> VDR machen um ein VDR-OSD zu bekommen.

Nur damit ich das richtig verstehe: Du startest mit Kodi, wechselst über den Skin-Eintrag zu vdr und hast dort kein OSD. Wie wechselst Du dann ohne OSD zu Kodi? Normal bräuchtest Du dafür ja den Befehl aus der commands.conf

Und wenn Du dann von Kodi (wie immer Du das ohne OSD auch gestartet gekriegt hast ) zu vdr zurückkehrst, hast Du dort OSD?

Hast Du zum Wechseln zwischen Kodi und vdr die von Zabrimus beschriebene Methode (siehe Abschnitt "Fast switch between Kodi and VDR") eingerichtet?

Paulaner: Startet Deine Box zuerst mit Kodi oder mit vdr? Wenn Du mit Kodi startest, dann setzt Kodi offenbar irgendwas, was softhdodroid braucht. Und das macht softhdodroid dann beim Wechsel von Kodi zu vdr offenbar nicht kaputt, sonst hättest Du ja nie ein vdr-OSD. Mir ist deshalb nicht klar, warum vdr bei einem Restart (Einstellungen - Neustart) dann doch etwas kaputt machen soll, denn technisch gesehen ist es kein Unterschied, ob vdr erstmals startet oder einen Neustart macht. Anders wäre es, wenn vdr beim Booten bereits mitgestartet wird und detached oder suspended im Hintergrund bleibt. Dann wäre der Wechsel von Kodi zu vdr kein kompletter Start von vdr, sondern nur ein attachen oder resume. Vielleicht kann Zabrimus dazu etwas sagen.

Oder startest Du die Box mit vdr? Und hast sofort OSD? Dann verstehe ich nicht, warum das OSD nach einem Reboot/Neustart nicht mehr da sein soll.

Was ich verstehen würde: Du bootest die Box mit vdr-Start und hast dabei nie ein OSD. Erst der Wechsel zu Kodi und wieder zurück zu vdr (dabei wird vdr erst detached oder suspended und beim Beenden von Kodi wieder attached/resumed) bringt ein OSD unter vdr. Beim detach/suspend und anschließendem attach/resume macht vdr evtl. nicht das gleiche wie bei einem kompletten vdr-Neustart und lässt deshalb Einstellungsänderungen, die Kodi vornimmt, unverändert. Deshalb wäre es für mich plausibel, dass Du bei einem vdr-Restart (Einstellungen-Neustart) dann möglicherweise wieder kein OSD hast, falls softhdodroid hier Initialisierungen durchführt, die nur bei einem vdr-Start erfolgen, nicht aber bei attach/resume.

Falls Du die Box mit Kodi-Start bootest, wäre die Frage: Wird vdr dabei bereits im Hintergrund detached/suspended mitgestartet, oder geschieht das erst beim ersten Wechsel von Kodi zu vdr? ( Zabrimus ?).
Und falls Du das so machst: Hast Du beim Wechsel von Kodi zu vdr dann ein OSD?

jojo61 : was ist eigentlich mit dem apiLevel? Der wird in VideoInit ermittelt und müsste, wenn es /dev/amstream_vbuf nicht mehr gibt bzw. dieses nicht geöffnet werden kann, mit 0 (UnknownApi) initialisiert bleiben. Ich sehe allerdings noch nicht, wie das das OSD betrifft.

Respekt, rell! Du gehst das sehr gründlich an.

Kannst Du die Tabelle nochmal etwas näher beschreiben? Die waagerechte Zeile oben stellt den aktuellen Playmode dar, in dem man sich gerade befindet. Die linke senkrechte Spalte steht für die Aktion, die dann aus diesem Playmode heraus aufgerufen wird. Korrekt?

Schwarz ist dann wahrscheinlich noch nicht der Code in vdr-2.7.4, wenn die Tabelle älter ist? Wofür stehen blau, grün und rot jeweils?

Weder Goto(Current) noch Goto(GetClosestIFrame(Current)) setzen die Wiedergabe genau an der Stelle fort, die vor dem resync angezeigt wurde. Ein kleiner Sprung um eine GOP zurück ist nicht so schlimm, aber wenn das nächste iFrame in der Zukunft liegt, können je nach GOP-Länge 1-2 Sekunden fehlen, und das sieht unschöner aus, als wenn nochmal kurz etwas wiederholt wird. Sowas wie GetLastIFrame wäre daher praktisch.

Es wird kaum möglich sein, im dvbplayer eine einheitliche Lösung zu finden, die für alle Ausgabedevices passt. Der Versuch, das im Ausgabeplugin dann so anzupassen, dass es harmoniert, ist deutlich aufwändiger, als wenige Codezeilen im dvbplayer für die die individuellen Bedürfnisse anzupassen. Ideal wäre es, wenn das Ausgabeplugin selbst bestimmen könnte, wann vdr ein Clear machen soll und wann ein resync mit Sprung zu welcher Stelle erfolgen soll.

Bei softhdodroid führt die Verlegung des Empty() dazu, dass nach dem Wechsel von Pause zu Slow Forward das Bild erstmal ein paar Sekunden stehen bleibt, ehe die Zeitlupe anläuft. Hat wohl was mit Buffering zu tun.