Beiträge von horchi

beta danke für die Erläuterungen, ich habe mir mit CoreElec hier ein ähnliches Setup zusammengestellt damit läuft der VDR auch wie geschmiert. Das verwende ich immer wenn der Odroid nur oder fast nur für den VDR da ist.

Bei dem Setup um welches es mir gerade geht ist der VDR nur ein kleiner Teil am Rande. In diesem Szenario habe ich ein paar Dinge welche ich im chroot nicht zum laufen bekomme und andere welche recht umständlich sind. Daher wäre es super wenn ich es unter Plain Ubuntu hinbekomme. Aktuell habe ich es mit apt-mark hold linux-odroid-n2 gelöst, nun kann ich einen Update machen und es läuft immer noch.

danke ich such mal in der Richtung weiter

habe gerade die Situation mit Kernel 4.9.337, im log kommt dieser Block an Meldungen 2-3 Mal /Sekunde:

Apr 25 16:57:46 odroid kernel: [ 4190.526016@0] spdif_info: rate: 48000, channel status ch0_l:0x100, ch0_r:0x100, ch1_l:0x200, ch1_r:0x200
Apr 25 16:57:46 odroid kernel: [ 4190.526027@0] aml_spdif_fifo_ctrl, bit depth:16, frddr type:1, toddr:type:1
Apr 25 16:57:46 odroid kernel: [ 4190.526172@0] spdif_b keep clk continuous
Apr 25 16:57:46 odroid kernel: [ 4190.526178@0] aml_spdif_close
Apr 25 16:57:46 odroid kernel: [ 4190.526253@0] audio_ddr_mngr: frddrs[0] released by device ff642000.audiobus:spdif_b
Apr 25 16:57:46 odroid kernel: [ 4190.526800@0] aml_spdif_open
Apr 25 16:57:46 odroid kernel: [ 4190.528187@0] audio_ddr_mngr: frddrs[0] registered by device ff642000.audiobus:spdif_b
Apr 25 16:57:46 odroid kernel: [ 4190.528411@0] set normal 512 fs /4 fs
Apr 25 16:57:46 odroid kernel: [ 4190.528444@0]          set spdifout clk:6144000, mpll:24576000
Apr 25 16:57:46 odroid kernel: [ 4190.528447@0]          get spdifout clk:6143997, mpll:24575987
Apr 25 16:57:46 odroid kernel: [ 4190.528449@0] aml_dai_set_spdif_fmt , fmt 0x4010
Apr 25 16:57:46 odroid kernel: [ 4190.528452@0] set normal 512 fs /4 fs
Apr 25 16:57:46 odroid kernel: [ 4190.528463@0]          set spdifout clk:6144000, mpll:24576000
Apr 25 16:57:46 odroid kernel: [ 4190.528465@0]          get spdifout clk:6143997, mpll:24575987
Apr 25 16:57:46 odroid kernel: [ 4190.528503@0] spdif_info: rate: 48000, channel status ch0_l:0x100, ch0_r:0x100, ch1_l:0x200, ch1_r:0x200
Apr 25 16:57:46 odroid kernel: [ 4190.528511@0] aml_spdif_fifo_ctrl, bit depth:16, frddr type:1, toddr:type:1

helfen die weiter, habt ihr eine Idee in welchem Bereich das Problem liegt?

VDR lässt sich nicht mehgr beenden, auch nicht mit kill -9, es bleibt ein defunct hängen: root 8884 3281 3 16:16 pts/1 00:01:25 [vdr] <defunct>

ich habe ein lokales DVB Device welches ich verwende wenn ich unterwegs bin - also der normal Betrieb.
Wenn das Wohnmobil zuhause im Hof steht schaue ich da drin kein TV außer zum testen, dann verwende ich streamdev mit Verbindung zum streamdev Server zuhause da es im Hof mit dem Ausrichten der Schüssel auf dem Wohnmobil etwas knapp ist am Dach vorbei zu kommen.

In beiden Betriebsarten läuft es mit 4.9.277 stabil und mit 4.9.337 bleibt es nach einiger Zeit hängen - zum Teil erst nach Stunden, je nachdem wie viel ich zappe oder wie oft ich den VDR Starte/Stoppe.

der Patch läuft wie du es beschreibst, das zu schnell laufen (und ab und zu kurz ruckeln) nach dem zappen ist weg, der Ton kommt damit bei mir gleichzeitig mit dem Bild. Das Bild steht hier dann noch kurz (deutlich unter einer Sekunde) dann läuft alles flüssig.
Finde es damit angenehmer beim Zappen!

ja ich habe wieder die aktuelle Plugin Version.
DVB kann ich ausschließen da es sowohl mit den lokalen DVB Treibern passiert als auch beim Betrieb über streamdev.

Die Box ist dann noch komplett ansprechbar und alles andere funktioniert dann noch einwandfrei. Nur der VDR läuft erst wieder (bzw. bringt erst wieder Bild) wenn ich gebootet habe.

Zitat von Dr. Seltsam

Ist es ein amlogic-Problem auf der Dekoderseite

Woran erkenne ich das bzw. wie kann ich das eingrenzen - vor allem wenn es eins von beidem ist hilft dann diese Informatiuon um ggf. etwas dagegen zu tun?

CoreELEC mit Ubuntu in einer chroot-Umgebung habe ich im Wohnzimmer da verwende ich der Odroid ausschließlich für den VDR das läuft super stabil.

Auf dem Odroid im Wohnmobil wird der VDR nur nebenbei verwendet, seine Hauptaufgabe dort ist eine Art Haussteuerung für alle mögliche Hardware und Geräte welche dort verbaut sind. Das alles in chroot ist mir zu frickelig und umständlich. Scheiterte bei meinen Versuchen schon an der dbus Verbindung zum systemd des CE.

Den Patch kann ich gern testen - ich vermute das er nur mit den Umschaltzeiten zu tun hat und keine Auswirkung/Verbesserung zu dem Problem unter 'pain' Ubuntu?

okay das scheint auch zu funktionieren

Verständnisfrage, muss man nach der Installation von dem im ersten Post hier genannten Ubuntu 20.04 Image sicherstellen das kein Update gemacht wird oder zumindest der Kernel dabei nicht aktualisiert wird? (Ich meine nicht den update auf 22.04, ... sondern nur die Aktualisierung innerhalb der 20.04).

habe nun nochmal das 20.04 Image installiert und den VDR ohne update/upgrade laufen lassen. Damit ist es nun seit Samstag Abend stabil und ich musste nicht booten :). Der Kernel des Images ist 4.9.277-122.

Versuche nun mit apt den Kernel auf 'HOLD' zu stellen und den Rest zu aktualisieren.

läuft damit länger bleibt aber auch hängen.

Hat das jemand hier auf dem Odroid ohne CoreElec laufen?

bin nun auf auf Commit ID 253e448 zurück, das ist der Stand auf welchem ich vor dem Update war.

* 2023-11-11 16:04:35 +0100 d2ec8b4 Enable Brightness & Contrast control by Dr. Seltsam

* 2023-11-08 14:14:41 +0100 0782d37 Fix stillpicture for H265 Streams

* 2023-10-20 10:59:49 +0200 464e7cc Improve PTS wrap Make FastChannelSwitch the default on new install

* 2023-09-28 09:32:24 +0200 253e448 (HEAD) Aktivate HBR for DD+

* 2023-08-24 12:41:17 +0200 1cb599b Changes for faster channelswitch from Dr. Seltsam

* 2023-08-07 12:32:01 +0200 f1d1990 Fix OSD Layer 0 Pixmap Alpha

* 2023-07-24 15:38:26 +0200 bcd7636 Set defaults for Audio Devices. No need for -a and -p Parameter anymore

Ggf. kann ich eingrenzen ob es an einem Kernel liegt welcher bei 'upgrade' mitgekommen ist oder an einer Plugin Änderung (ich weiß nicht ob ein neuer Kernel mitgekommen ist).

Bislang hat es damit mehrere VDR Restarts klaglos überstanden, ich beobachte es.

bin da extra auf 20.04 geblieben da es ja mit 22.04 nicht klappt.
Hoffe das es nicht nur noch unter Coreelec geht, dann müsste ich bei drei meiner Installation zurück auf den Raspi.

das Problem tritt hier auf:

Zitat von horchi

ich habe ein Problem mit dem VDR (2.6.3) auf dem Odroid N2+ mit Ubuntu 20.04.Da der Im Wohnmobil ist verwende ich ihn nicht durchgängig, letzte Saison lief er noch prima. Nun habe ich ihn ich im Frühjahr aktualisiert (apt update/upgrade und das aktuellste softhdodroid aus dem git).

Hier läuft es:

Zitat von horchi

Eine andere Installation in einer chroot Umgebung unter CoreElec läuft ohne Probleme

hab den Effekt nur unter Plain Hardkernel Ubuntu 20.04 ohne Coreelec

ich habe ein Problem mit dem VDR (2.6.3) auf dem Odroid N2+ mit Ubuntu 20.04.Da der Im Wohnmobil ist verwende ich ihn nicht durchgängig, letzte Saison lief er noch prima. Nun habe ich ihn ich im Frühjahr aktualisiert (apt update/upgrade und das aktuellste softhdodroid aus dem git).

Grundsätzlich funktioniert es noch, nach einiger Zeit zum Teil erst nach mehreren Stunden bleibt er hängen. Dann hilft nur booten, Neustart des VDR genügt nicht.

In der Situation kommt beim Start des VDR im syslog:

Apr 20 12:03:10 usb kernel: [11122.844869@2] aml_spdif_open

Apr 20 12:03:10 usb kernel: [11122.844976@2] audio_ddr_mngr: frddrs[0] registered by device ff642000.audiobus:spdif_b

Apr 20 12:03:10 usb kernel: [11122.845921@2] fb: osd[0] enable: 0 (vdr)
Apr 20 12:03:10 usb kernel: [11122.869526@2] the demux           clock on, ref cnt: 1
Apr 20 12:03:10 usb kernel: [11122.869530@2] the parser_top      clock on, ref cnt: 1
Apr 20 12:03:10 usb kernel: [11122.869532@2] the vdec            clock on, ref cnt: 1
Apr 20 12:03:10 usb kernel: [11122.869547@2] the clk_vdec_mux    clock on, ref cnt: 1
Apr 20 12:03:10 usb kernel: [11122.869564@2] vdec mux clock is 499999992 Hz
Apr 20 12:03:10 usb kernel: [11122.869591@2] vdec_create instance ffffff800851d000, total 1
Apr 20 12:03:10 usb kernel: [11122.869597@2] the demux           clock on, ref cnt: 2
Apr 20 12:03:10 usb kernel: [11122.869598@2] the parser_top      clock on, ref cnt: 2
Apr 20 12:03:10 usb kernel: [11122.869599@2] the vdec            clock on, ref cnt: 2
Apr 20 12:03:10 usb kernel: [11122.869619@2] vdec_create instance ffffff8008581000, total 2
Apr 20 12:03:10 usb kernel: [11122.869625@2] The fw has been loaded.
Apr 20 12:03:10 usb kernel: [11122.869628@2] vdec_init, dev_name:ammvdec_mpeg12, vdec_type=VDEC_TYPE_FRAME_BLOCK
Apr 20 12:03:10 usb kernel: [11122.869784@2] vdec: Decoder device ammvdec_mpeg12 driver probe failed.
Apr 20 12:03:10 usb kernel: [11122.869786@2] video_port_init 632, vdec_init failed
Apr 20 12:03:10 usb kernel: [11122.869803@2] video_port_init  failed
Apr 20 12:03:10 usb kernel: [11122.872677@2] adec_release
Apr 20 12:03:10 usb kernel: [11122.873101@2] Audio stbuf alloced at 00000000cfc00000, secure = 0, size = 1572864
Apr 20 12:03:10 usb kernel: [11122.873115@2] amstream_do_ioctl error :ffffffffffffffed, 401053c2
Apr 20 12:03:10 usb kernel: [11122.878843@2] vdec_release instance ffffff8008581000, total 2
Apr 20 12:03:10 usb kernel: [11122.878855@2] the vdec            clock off, ref cnt: 1
Apr 20 12:03:10 usb kernel: [11122.878860@2] the parser_top      clock off, ref cnt: 1
Apr 20 12:03:10 usb kernel: [11122.878861@2] the demux           clock off, ref cnt: 1
Apr 20 12:03:10 usb kernel: [11122.878866@2] vdec_disable_DMC input->target= 0x0
Apr 20 12:03:10 usb kernel: [11122.878867@2] vdec_release instance ffffff800851d000, total 1
Apr 20 12:03:10 usb kernel: [11122.878880@2] the clk_vdec_mux    clock off, ref cnt: 0
Apr 20 12:03:10 usb kernel: [11122.878882@2] the vdec            clock off, ref cnt: 0
Apr 20 12:03:10 usb kernel: [11122.878884@2] the parser_top      clock off, ref cnt: 0
Apr 20 12:03:10 usb kernel: [11122.878886@2] the demux           clock off, ref cnt: 0
Apr 20 12:03:10 usb kernel: [11122.878904@2] vfm_map_store:rm all
Apr 20 12:03:11 usb kernel: [11123.882142@2] vfm_map_store:add default decoder ppmgr deinterlace amvideo
Apr 20 12:03:11 usb kernel: [11123.883298@2] vfm_map_store:add default_amlvideo2 vdin1 amlvideo2.1
Apr 20 12:03:11 usb kernel: [11123.889559@2] vfm_map_store:add dvblpath dvbldec amvideo
Apr 20 12:03:11 usb kernel: [11123.894840@2] vfm_map_store:add dvelpath dveldec dvel
Apr 20 12:03:11 usb kernel: [11123.899868@2] vfm_map_store:add dvhdmiin dv_vdin amvideo
Apr 20 12:03:11 usb kernel: [11123.929465@2] fb: osd[0] enable: 1 (vdr)
Apr 20 12:03:11 usb kernel: [11123.946144@2] SR enable
Apr 20 12:03:11 usb kernel: [11123.946157@2] the demux           clock on, ref cnt: 1
Apr 20 12:03:11 usb kernel: [11123.946159@2] the parser_top      clock on, ref cnt: 1
Apr 20 12:03:11 usb kernel: [11123.946161@2] the vdec            clock on, ref cnt: 1
Apr 20 12:03:11 usb kernel: [11123.946174@2] the clk_vdec_mux    clock on, ref cnt: 1
Apr 20 12:03:11 usb kernel: [11123.946188@2] vdec mux clock is 499999992 Hz
Apr 20 12:03:11 usb kernel: [11123.946223@2] vdec_create instance ffffff8008d2f000, total 1
Apr 20 12:03:11 usb kernel: [11123.946273@2] vdec_disable_DMC input->target= 0x0
Apr 20 12:03:11 usb kernel: [11123.946274@2] vdec_release instance ffffff8008d2f000, total 1
Apr 20 12:03:11 usb kernel: [11123.946282@2] the clk_vdec_mux    clock off, ref cnt: 0
Apr 20 12:03:11 usb kernel: [11123.946284@2] the vdec            clock off, ref cnt: 0
Apr 20 12:03:11 usb kernel: [11123.946285@2] the parser_top      clock off, ref cnt: 0
Apr 20 12:03:11 usb kernel: [11123.946287@2] the demux           clock off, ref cnt: 0
Apr 20 12:03:11 usb kernel: [11123.946310@2] fb: clear: osd 0
Apr 20 12:03:12 usb kernel: [11124.623584@1] fb: clear: osd 0

und im VDR log:

Apr 20 12:03:10 usb vdr: Disable Noise reduction


Apr 20 12:03:10 usb vdr: Disable HDR2SDR
Apr 20 12:03:10 usb vdr: Initial Screen 1920-1079 set to 1920-1080
Apr 20 12:03:11 usb vdr: AmlCodec: amstream version : 2.0
Apr 20 12:03:11 usb vdr: aml ApiLevel = 2  Screen 1920-1080 using OSD dma: yes H264-PIP: 1 MPEG2 PIP 0
Apr 20 12:03:11 usb vdr: Odroid New HW Decoder
Apr 20 12:03:12 usb vdr: Set Playmode 1
Apr 20 12:03:12 usb vdr: set trickspeed to 0
Apr 20 12:03:12 usb vdr: [softhddev]GetOsdSize: 1920x1080 1

root@womo ~/> lsb_release -a

No LSB modules are available.

Distributor ID: Ubuntu
Description:    Ubuntu 20.04.6 LTS
Release:        20.04
Codename:       focal


root@womo  ~/> uname -a

Linux usb 4.9.337-138 #1 SMP PREEMPT Thu Jul 20 04:35:23 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

Eine andere Installation in einer chroot Umgebung unter CoreElec läuft ohne Probleme
Habt Ihr eine Idee wo das klemmen könnte? Hat das jemand in dieser oder ähnlicher Konstalltion am

ist behoben, fix ist im git

kann ich reproduzieren, ich sehe es mir an.

Bei dem letzten Vergleich liefert epglv korrekt 0. nur epglvr berechnet die Prozentuale Abweichung falsch. Sollte einfach zu beheben sein. Interessant das es nur bei dir auftritt

CKone hast du die selbe MariaDB Version, ich bin noch bei 10.5.18

und welche Server Version?

Hast du die epglv Funktionen mit der Version gebaut?

was passiert denn wenn du das Statement am SQL Prompt ausführst, dabei die ? gegen den Titel gegen den der Sendung ersetzten:

select actor, audio, camera, category, channelid, channelname, country, description, director, duration, episodecompname, episodecomppartname, episodecompshortname, episodelang, eventid, flags, folder, fsk, genre, recgroup, guest, imgid, inuse, job, longdescription, md5path, moderator, music, name, ngenre, numrating, other, owner, path, producer, rating, screenplay, scrinfoepisodeid, scrinfomovieid, scrinfoseriesid, scrmovieid, scrnew, scrseriesepisode, scrseriesid, scrsp, shortreview, shorttext, starttime, state, tipp, title, topic, txtrating, vdruuid, year, 100 - ifNull(epglvr(title, ?), 100), 100 - ifNull(epglvr(shorttext, ?), 100) from recordinglist where  (state <> 'D' or state is null)and epglvr(title, ?) < 47;

sagt mir nichts, hat auch glaube nichts mit dem Plugin zu tun.

es ist für das EPG als Client Server Architektur aufgebaut bei welcher der epgd der Server und der VDR (bzw. die beiden Plugins) der Client ist.

Ein sharen der Daten zwischen den Clients bzw. über deren Filesystem ist dabei nicht vorgesehen. Natürlich wäre das technisch denkbar ist halt hier nicht der Ansatz.

Mir würde eher eine Lösung vorschweben welche (hinsichtlich der Bilder) Komplett auf das Filesystem verzichtet, das ginge jedoch nur mit Anpassung aller Plugins welche auf die Bilder zugreifen.