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.
Beiträge von horchi
-
-
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:
Code
Alles anzeigenApr 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.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:
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:
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:Code
Alles anzeigenApr 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:
Code
Alles anzeigenApr 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
Code
Alles anzeigenroot@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:
Codeselect 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.