Posts by CKone

Quote from Dr. Seltsam

horchi hat auch einen N2+? Gleiche RAM?

ja, beide 4Gb

Quote from jojo61

Warum ihr nun aber Probleme mit UHD habt ist mir unklar. Ich habe da immer Ton und Bild.

horchi hatte auch Probleme ab d74ba03, allerdings betrifft das bei uns beiden nur die HLG Sender

wird sind auch auf odroid n2+

hier war alles etwas strubbelig nach der Aktion, nachdem ich jetzt TV, odroid und AV Receiver neu gestartet habe: "Nicht unterstütztes Videoformat" ist jetzt wieder weg und es läuft auch mit 384*1024

was mir aber schon länger aufgefallen ist (also jetzt länger als 14 Tage): nach dem Wechsel von SDR nach HDR hab ich oft keinen Ton, der kommt dann wenn ich zwischen den HLG Sendern hin und herschalte und ist dann auch stabil wenn er denn da ist.

bei horchi weiterhin Ton ohne Bild, selbst mit 512. => vllt liegts auch an Toleranzen der TV Hardware?

abgesehen das mein TV mit der Änderung: Nicht unterstütztes Videoformat anzeigt funktioniert es mit der 512.

Bei horchi und anderem TV kommt Ton aber kein Bild

Quote from Dr. Seltsam

versuch doch mal, in softhddev.c den Wert

Code

#define AUDIO_MAX_BUFFERS (260 * 1024)

schrittweise hochzusetzen, bis 512 * 1024. Damit wird der Sinn des neu eingeführten Limits zwar ausgehebelt, aber es sollte sich so wie vorher verhalten. Die Frage ist, ob wir dann einen Weg finden, nur für UHD den benötigten höheren Wert zu nehmen, denn für HD haben auch 150 gereicht. Je höher der Buffer, desto länger das Umschalten.

also mit AUDIO_MAX_BUFFERS (512 * 1024) läuft es schon mal wieder, danke

Quote from rell

Dr. Seltsam: Interessehalber kurze Zwischenfrage... was ist eigentlich der Grund für die chroot Umgebung? Nur um zu kompilieren?

ja das ist einfach nicht praktikabel: wenn du dich minimal damit beschäftigen und einfach nur TV schauen willst ist euer Image super, aber wenn du selbst entwickelst oder so wie ich immer nah an den Entwicklern bist ist das schon extrem hinderlich. - alleine heute das Problem mit softhdodroid mit jojo61 zu testen wird da schon zum Problem.

Ansonsten bin ich sehr großer Fan von eurem Image und überlege es, wenn ich aus dem Urlaub zurückkomme, wieder unter das chroot zu machen. Ich hatte auch nicht auf dem Schirm das nur mit eurem Kernel da PIP unter softhdodroid funktioniert.

Was mir da noch fehlen würde wäre ein funktionierendes irmplircd für den STM32 Empfänger von Emma53 , in dem Zusammenhang auch die Datei "de.yavdr.lircd2uinput.conf" unter /etc/dbus-1/system.d. (gibts im lircd2uinput yavdr Paket).

Das von Dr. Seltsam angesprochene Problem mit der Geschwindigkeit beim Kanalwechsel kann ich übrigens so bestätigen, das liegt aber irgendwo beim vdropt selber: wenn ich auf eurem Image den vdr in meinem ubuntu chroot starte tritt das nicht auf.

das hat leider nichts gebracht hier jojo61 , es geht auch nicht nur um Audio sondern das das Bild bei UHD mit HLG einfach steht.

Es ist auch kein generelles UHD Problem, QVC/QVC2 funktionieren

Moin Moin

horchi hat mich gerade darauf Aufmerksam gemacht, dass UHD mit HLG nur Standbild bringt. Er ist auf CE 19, ich auf 20.

Bringt bei live genauso wie bei Wiedergabe nur Standbild aber läuft nicht an: d90c638 13892df läuft hier noch, ich hangel mich mal nach vorn der Fehler tritt erstmalig in d74ba03 auf

Epgd aktualisiert und die Plugins nicht neu gebaut? Hier läuft alles rund mit der aktuellen Version

ich hatte auch lange ein Zabrimus Image unter dem chroot, nutze jetzt das originale CE20.

Auch wenn es hier etwas OT ist: was sind eure genauen Gründe weiter auf Zabrimus aufzubauen, bisher fehlt mir hier nichts außer das ich es nicht hinbekomme die "de.yavdr.frontend.conf" und die "de.yavdr.lircd2uinput.conf" nach /etc/dbus-1/system.d zu bekommen?

Ich hatte schon versucht das Verzeichnis mit "mount -o bind /storage/.config/dbus-1/system.d /etc/dbus-1/system.d" vor start des dbus Deamon im Filesystem auszutauschen aber ich bekomm es irgendwie nicht funktional hin das ich mir den Service mit "dbus-send --system --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames" anzeigen kann.

Ist aber jetzt auch nicht kriegsentscheidend für mich.

Quote from jojo61

Habs grad gefixt und eingecheckt

ist super jetzt mit dem aktuellen Stand, alle meine Anmerkungen sind umgesetzt bzw behoben. Damit lass ich es jetzt über das Wochenende laufen aber ich bin schwer begeistert - war ich ja gestern schon. Wollte auch gestern Abend nur den ein oder anderen vom fehlerhaften Update abhalten und keine Aufruhr machen

Dass das Bild während einer Wiedergabe reproduzierbar an einer Stelle stehen bleibt tritt wirklich sehr sehr selten auf (vllt 3x in 2 Monaten), ich vermute das es ein kurzzeitiges Problem im Empfangsstream war, mit dem andere Frontends etwas großzügiger umgehen - Wenn hier jemand früher als ich einen Beispielschnipsel beisteuern kann wird jojo61 sich sicher freuen. Bin selber auch die zweite Märzhälfte in Urlaub.

Sicher? Wiedergabe, nicht Aufnahme. kann ich hier reproduzieren: mit dem Stand von gestern ist gut.

das stimmt leider was nicht, auch wenn die Bugs beseitigt sind hab ich mit der aktuellen Version eine CPU von 100% während der Wiedergabe.

Vielen Dank jojo61 , das war nochmal ein sehr großer Schritt nach vorn für ein ohnehin schon sehr gutes Frontend!

Gruß Christian

so nach gut einem Monat softhdodroid im produktiven Einsatz wollte ich kurz meine Beobachtungen schildern. Es kann auch sein das hier und da was hausgemachtes dabei ist, aber vllt können andere ja ähnliches bestätigen:

- also das eine voll aufgerödeltes OSD (shady, logos, scraper) auf einem odroid n2+ langsamer ist als mit einer GT630 oder auf einem nuc8 kann ich nicht bestätigen, das läuft hier wirklich flüssig

- Was am OSD nicht so toll ist sind (bei 3840) die skalierten Flächen, also wenn in der Programm oder Aufnahmen Ansicht ein viertel des Bildschirms im Fenster angezeigt wird: bei öffnen des Menu ist das noch ok aber sobald sich das Programm im Fenster ändert passt da die Skalierung nicht. Zum Beispiel in der Aufnahmensicht ist es solang ok bis man entweder die Wiedergabe mit Stop beendet und er auf TV zurückspringt oder mit den Kanaltasten ein Programm weiter schaltet wenn man einfach nur im Menu war. Beim Programmmenu identisch und mit softhddrm kein Problem. Aufgefallen war mir da das die setup Option zur OSD Größe die es unter softhddrm noch gab hier nicht mehr da ist?

- das Spulen, vor wie zurück läuft super. (benutze ich allerdings selten)

- was leider nicht so gut läuft ist das Springen mit grün/gelb um jeweils eine Minute, da kann man zB mit softhddrm einfach den Finger drauf halten und kann dann zB 20 Minuten zurückgehen. Hier benötigt es wirklich sehr viele Einzelklicks um dasselbe zu erreichen.

- seeeehr selten, vllt einmal pro Woche bleibt die Wiederhabe einer Aufnahme plötzlich stehen, ich kann dann kurz zurücklaufen lassen und mit einem 10s Sprung drüber, aber die Wiedergabe selber stoppt immer wieder an der Stelle. Ich kann da gern mal eine Aufnahme behalten und einen Schnipsel rausschneiden bei dem das auftritt. - unter softhddrm laufen die selben Sequenzen sauber.

- jump'n'run über markad Schnittmarken: das kann ich gar nicht so richtig greifen, sehr selten läuft es sauber, meistens läuft aber der Ton weiter, das Bild geht 2-3s in einen schnellen Vorlauf mode bevor er dann doch über die Werbung springt und danach dann sofort sauber weiter läuft.

Alles in Allem Jammern auf sehr hohem Nivuea, nichts davon ist wirklich lebenswichtig an dem tollen Plugin.

Aber vllt hat ja schon mal jemand ähnlich Sachen beobachtet oder sogar lokal beheben können.

das kann ich bestätigen aber ich könnte schwören das geht schon ganz lange nicht, und zwar seit Mike was an der URL zum eplists gemacht hat

Jörg ist diese Woche in Urlaub.

Quote from jrie

0.10.2 ist ausreichend, aber 0.10.1 nicht. In @horchi's git wird noch CoreELEC 19.5 erwähnt, und da ist noch 0.10.1 drin.

Da liegen 5 Jahre dazwischen, so lange wurde eine veraltete Version benutzt.

ja der hat auch noch 19.5 installiert, schreibe ich ihm mal in den Urlaub das er erst mal neu installieren muss

Wie zeigt sich das Problem mit der falschen Version dann genau?

das kann ich aber so nicht bestätigen jrie , mein CoreELEC 20 scheint da frischer zu sein:

Using username "root".
root@192.168.130.18's password:
##############################################
#                  CoreELEC                  #
#            https://coreelec.org            #
##############################################


CoreELEC (official): 20.0-Nexus (Amlogic-ng.arm)
Machine model: Hardkernel ODROID-N2Plus
CoreELEC dt-id: g12b_s922x_odroid_n2plus
Amlogic dt-id: g12b_w400_b


CKone:~ # lircd -v
lircd 0.10.2

image von hier: https://github.com/CoreELEC/CoreELEC/releases/tag/20.0-Nexus

sogar frischer als das 0.10.1 von jammy im chroot, ist das 0.10.2 nicht hinreichend?

Quote from seahawk1986

Könnte es sein, dass /dev zu dem Zeitpunkt noch nicht in das für das chroot genutzte Verzeichnis gemountet wurde?

Wenn ich das richtig sehe, passiert das bei euren Skripten in https://github.com/horchi/vdrO…scripts/ubuntu-init.sh#L7 - dann bräuchte die irmplircd@.service noch eine Abhängigkeit von der ubuntu.service

Code

[Unit]
Description=irmplircd - a daemon for IRMP receivers
After=ubuntu.service
Requires=ubuntu.service

das hat wunderbar funktioniert, danke Alexander!

Die Fernbedienung selber läuft jetzt insgesamt prima auf dem CoreELEC20 und dem irmplircd aus dem Ubuntu chroot, danke noch mal an jrie für sein Geduld beim debuggen der Timings.

Die 5V USB Standby Spannung konnte ich am Ende aktivieren aus dem CoreELEC Menu, das war aber irgendwie zickig aber sie war plötzlich da als ich mit den Einstellungen für USB Power und WOL rungespielt habe. Den Powerkey auf dem gpio konnte ich hiermit aktivieren: https://www.bachmann-lan.de/od…t-einfachem-power-switch/ und den Einschalter dann mit Pin 9 und11 GPIO verbinden, die MCE Taste hatte Emma53 ja schon passend angelernt.

Die Fernbedienung läuft jetzt anders als mit dem meson-ir wirklich wie man das aus den konventionellen VDR kennt, ich bin wirklich begeistert. Im klaren muss man sich aber darüber sein, dass da schon ein paar Kabel an dem Empfänger sind die es zu verstauen gilt, das ist aber hier bei mir kein Problem.

Sorry, falsch abgebogen :o