Dauerspinner bei mp3 Wiedergabe

[Alex23]

Bei Image 15496 wird im BMediacenter nur ein Lied abgespielt, trotz repeat=all. Wenn man dann ein neues Lied auswählt oder mit exit den Player versucht zu verlassen, dann kommt es zum Dauerspinner.
Wenn man mp3s über den Aufnahme-Browser versucht abzuspielen, wird auch nur die Erste abgespielt. Nach Versuch mit exit den Browser zu verlassen kommt auch ein Dauerspinner.
Selbes Verhalten bei Image 15085. Jeweils getestet mit nacktem Image (nicht mal die Kanalliste wurde zurückgespielt).

Ein kurzer Test bei der Spark7162 ergab auch ein Dauerspinner mit Image 15496. Es könnte also ein generelles SH4 Problem sein.
Im Forum habe ich diesbezüglich noch nichts gelesen. Benutzt sonst keiner den mp3-Player oder liegt es doch an meiner Konfiguration?

Falls nicht, liegt es also vermutlich am Player an sich, da es zum selben Verhalten im BMC und Aufnahme-Browser kommt.
Bei Image 14258, zumindest beim Topf, funktionierte der mp3-Player noch. Hier getestet mit einem Backup (mit Plugins zugemülltes und aufgeblähtes Image).
Welcher Player spielt denn Musik ab: ffmpeg, gst oder ein ganz anderer.
Gab es eine Änderung zwischen 11.2015 und 05.2016?

Laut Log tut der Player zumindest so, als wolle er das nächste Lied abspielen. Es kommt aber nichts raus.

-----====== HDMU 15496 enigma2 Git 4206 ======-----




BusyBox v1.24.1 (2016-10-03 15:22:20 CEST) built-in shell (ash)

TOPF:~# export PS1='MAT:\w# '
MAT:~# KEY by code: 160 - OK/LIST
**** 37376 19 ****
[SEM] UP
KEY_PRESS - 160 19
++++ 0 ms ++++
< 4829.460> playing 4097:0:0:0:0:0:0:0:0:0:/media/hdd/music/01 - A-ha - Take On Me.mp3
KEY by code: 160 - OK/LIST
**** 39 19 ****
++++ 85 ms ++++
KEY_RELEASE - 160 00 19 19 CAUSE=Timeout
---- 123 ms ----
[SEM] DOWN
TuxTxt stopped service 13f0
cleaning up
TuxTxt cache cleared
< 4830.413> [Timeshift disabled]
< 5060.214> Next up: /media/hdd/music/01 - Backstage.mp3
< 5060.295> playing 4097:0:0:0:0:0:0:0:0:0:/media/hdd/music/01 - Backstage.mp3
KEY by code: 66 - EXIT
**** 1726336 0 ****
[SEM] UP
KEY_PRESS - 66 0
++++ 0 ms ++++
KEY by code: 66 - EXIT
**** 45 0 ****
++++ 75 ms ++++
KEY_RELEASE - 66 00 0 0 CAUSE=Timeout
---- 123 ms ----
[SEM] DOWN

-----====== HDMU 15085 enigma2 Git 4130 ======-----




BusyBox v1.24.1 (2016-05-23 00:40:58 CEST) built-in shell (ash)

TOPF:~# export PS1='MAT:\w# '
MAT:~# KEY by code: 160 - OK/LIST
**** 16529 14 ****
[SEM] UP
KEY_PRESS - 160 14
++++ 0 ms ++++
< 536.033> playing 4097:0:0:0:0:0:0:0:0:0:/media/hdd/music/01 - A-ha - Take On Me.mp3
KEY by code: 160 - OK/LIST
**** 52 14 ****
++++ 69 ms ++++
KEY_RELEASE - 160 00 14 14 CAUSE=Timeout
---- 122 ms ----
[SEM] DOWN
TuxTxt stopped service 68
cleaning up
TuxTxt cache cleared
< 536.819> [Timeshift disabled]
< 767.074> Next up: /media/hdd/music/01 - Backstage.mp3
< 767.128> playing 4097:0:0:0:0:0:0:0:0:0:/media/hdd/music/01 - Backstage.mp3
KEY by code: 66 - EXIT
**** 722763 15 ****
[SEM] UP
KEY_PRESS - 66 15
++++ 0 ms ++++
KEY by code: 66 - EXIT
**** 51 15 ****
++++ 73 ms ++++
KEY_RELEASE - 66 00 15 15 CAUSE=Timeout
---- 121 ms ----
[SEM] DOWN

[rantanplan]

Was man sieht ist die Verwendung von gst (4097) und da zickt was.
Dachte eigentlich das mp3 und VideoDateien via 4099 abgespielt werden.
Dann läuft es sicher einwandfrei.

[Alex23]

Ich habe jetzt nochmal etwas genauer, bzw. manuell im Forum recherchiert (mp3 ist als Suchbegriff leider zu kurz).
Das Problem ist wohl doch genau so bekannt wie ich es geschildert habe. Siehe hier (http://www.hdmedia-universe.com/board/showthread.php?9906-HDMU_14814_E2_ufs913). Nach dem Durchprobieren weiterer Images, ist 14317 das letzte, welches mir zur Verfügung stand und mp3s normal abspielen kann. Leider funktioniert in 14317 das Abspielen alter Aufnahmen nicht.

4099 ist dann wohl ffmpeg, richtig? In 14258 wird aber auch gst als mp3-Player verwendet, allerdings funktionierend.

Scheinbar nutzt in den neueren Images keiner die mp3-Funktion oder es wurde schon darauf hingewiesen, dass das Problem bekannt ist und die User diesbezüglich geduldig sein sollen. Falls letzteres der Fall ist, wollte ich keinen Stress machen und entschuldige mich dafür.

Ich habe jetzt erst mal das 14258 neu installiert, da es scheinbar das letzte ist, in dem mp3s und Aufnahmen funktionieren.
In meinen anfänglichen Tests habe ich bei den neueren Images das alte BMC von 14258 reinkopiert. Was ja offensichtlich keine Abhilfe bezüglich des mp3-Abspielens brachte. Der Player ist tiefer im System verankert nehme ich an, sodass ein einfacher Tausch auch nicht möglich ist.
Mir ist noch in Erinnerung, dass bei Burnig Series im BMC anfangs die Streams von einem User auf ffmpeg (4099?) umgeleitet wurden, bevor es in den Optionen auswählbar war.
Ist das bei mp3s auch möglich? Ansonsten fällt mir nichts anderes ein, als erst mal bei 14258 zu bleiben.

Apropos 14258: Hat noch jemand zufällig dieses Image für Spark7162 und kann es mir irgendwo hochladen?

[suchmich1983]

In meinen anfänglichen Tests habe ich bei den neueren Images das alte BMC von 14258 reinkopiert. Was ja offensichtlich keine Abhilfe bezüglich des mp3-Abspielens brachte. Der Player ist tiefer im System verankert nehme ich an, sodass ein einfacher Tausch auch nicht möglich ist.

BMC ist ja nur das FrontEnd wenn du so willst. Das eigentliche Abspielen von Media-Files passiert mit GST.
Du kannst also die FrontEnds tauschen noch und nöcher, dein Probelm aber bleibt.

[Alex23]

Ich dachte aus meinen Beiträgen wäre es ersichtlich, dass mir bewusst ist, dass es am Player liegen muss und weder ein Tausch des BMC noch des Aufnahme-Browsers noch eines anderen "Frontends" Abhilfe schaffen wird, solange mit gst abgespielt wird.

Falls nicht, liegt es also vermutlich am Player an sich, da es zum selben Verhalten im BMC und Aufnahme-Browser kommt.
Ich hatte mir mein altes Image (14258) leider mit einem unüberlegten Online-Update zerschossen. Also hab ich mal das neueste Image ausprobiert. Desweitern gab es laut Forum Probleme mit dem HDMU-Center und dem BMC. Also war meine erste Überlegung, nachdem mp3s nicht richtig abgespielt wurden, das Austauschen des BMC. Als das nichts brachte, sowie der Fehler auch im Aufnahme-Browser auftrat, musste es meiner Meinung nach offensichtlich am Player liegen.

In meinen anfänglichen Tests habe ich bei den neueren Images das alte BMC von 14258 reinkopiert. Was ja offensichtlich keine Abhilfe bezüglich des mp3-Abspielens brachte.
Nun zu meinen weiterhin offenen Fragen:

1. Ist den Entwicklern bekannt, dass es seit ca. 14493 bis aktuell ein Problem mit dem gst beim Abspielen mit mp3s gibt?
2. Wie tief ist der gst im Image verankert, bzw. lässt er sich einfach tauschen? (-Vermutlich keine Alternative)
3. Wie realistisch ist die von mir bereits erwähnte Umleitung auf 4099 im BMC-AudioPlayer? Wie hier (http://www.hdmedia-universe.com/board/showthread.php?9134-SH4-Streaming-Problem&p=104531&viewfull=1#post104531) von rantanplan für Burning Series vorgenommen?

4. Und am Wichtigsten:
Hat noch jemand zufällig das Image 14258 für Spark7162 und kann es mir irgendwo hochladen?

@rantanplan: Da hat mir ja genau der User geantwortet, der für die von mir später vorgeschlagene Umleitung auf 4099 verantwortlich war. Danke für deinen Beitrag, der war zumindest Hilfreich.

[TheChip]

Zu 1.: Wenn es keine Rückmeldungen gibt, bekommen wir nicht mit, wenn es Probleme gibt.
Zu 2.: Der GST ist nicht ohne weiteres tauschbar.
zu 3.: Die Umleitung auf den FFM wurde Dir doch gerade deshalb empfohlen, weil damit wahrscheinlich Dein Problem behoben ist. Probier es bitte einfach aus und berichte. So ein Forum lebt vom mitmachen, aber leider ist seit einiger Zeit zu beobachten, das kaum noch einer infos gibt, was geht und was nicht. Siehe dazu Punkt 1. (Ich spreche nicht für alle, da es durchaus noch engagierte User gibt)
Zu 4. kann ich leider nichts sagen, da ich das Image nicht hab.

Nachtrag: Zur Frage GST im Image 14258: da es für den GST ja auch Aktualisierungen gibt, ist es durchaus möglich, daß im alten Image MP3 noch sauber mit GST lief.

[Alex23]

Danke für deine Antwort.

Zu 1. Es gab bereits Rückmeldung zum mp3-Problem bei Image 14814 (http://www.hdmedia-universe.com/board/showthread.php?9906-HDMU_14814_E2_ufs913).
Jetzt kamen mir 2 Szenarien in den Sinn:


a) Euch war nicht bewusst, dass dieser Fehler noch existiert.


b) Euch war es bewusst, aber die Priorisierung war nicht so hoch; was ich absolut verstehen kann. Ich hatte das Forum in letzter Zeit nicht mehr so gut nachverfolgt und wollte nicht damit nerven, falls das Problem bekannt ist und gefühlt jeder 3. User damit ankommt.

Da ihr dieses Problem also nicht mehr wahrgenommen habt, habe ich hiermit dann wohl Rückmeldung gegeben. Falls etwas getestet werden soll, bin ich gerne bereit dazu.


Zu 2. Dachte ich mir.

Zu 3. Die Umleitung wurde mir nicht empfohlen. rantanplan dachte, mp3s würden an sich schon mit ffmpeg abgespielt.
Dachte eigentlich das mp3 und VideoDateien via 4099 abgespielt werden.
Dann läuft es sicher einwandfrei.
Die Umleitung hatte ich ins Spiel gebracht.


Mir ist noch in Erinnerung, dass bei Burnig Series im BMC anfangs die Streams von einem User auf ffmpeg (4099?) umgeleitet wurden, bevor es in den Optionen auswählbar war.
Ist das bei mp3s auch möglich?
Ich war mir aber nicht sicher, ob das überhaupt geht, da ich leider nicht so sehr bewandert bin in der Softwareentwicklung.


Was mich zum nächsten Problem führt: rantanplan hatte damals die Python-Datei verändert. Mir ist derzeit nicht bewusst, wie ich das ebenso durchführen kann. Ich gehe davon aus, dass es eine komplexere Thematik ist und es nicht mal eben schnell ohne Kenntnis geändert und ausprobiert ist. Ich las noch über eine Serviceapp, die unter Extensions zu finden sein soll, mit der man den Player wählen könnte. Diese wird mir aber nicht angezeigt, auch nicht unter den anderen Kategorien, ist also vermutlich nur für mips.


Zu 4. Ok

Zu Nachtrag: Ja, es ist mir ja jetzt bewusst, dass es mit einer Änderung am gst zu tun hat.

[rantanplan]

Das Forum lebt von den User die Mitteilungen machen ist sicher richtig.
Aber ab dann kann ich nicht so ganz zustimmen...aber egal...

Die generelle Abänderung der Files bzgl Mediaframwork ist natürlich auch möglich, müsste ja in der ServiceReference stehen...mhhh
Mal gucken...
Das Handling wurde immer mal wieder geändert, obwohl die meisten User bei sh4 durchaus als Freunde des ffmpeg gelten.

- - - Aktualisiert - - -

Ok...geguckt und verändert
also einfach mal probieren...
Pfad ist usr/lib/enigma2/python-> da liegt die ServiceReference als pyo.
Ich hänge dir die auf 4099 abgeänderte py hier an. Einfach die entpackte Datei dorthin kopieren und die pyo löschen.
Neustart des Receiver machen.
Dann testen ob es läuft.
14598

[Alex23]

Danke.
Habe es jetzt mit 14258 getestet, sollte ja egal sein.
Laufen tut es. Aber es wird immer noch mit 4097 abgespielt.

-----====== HDMU 14258 enigma2 Git 3973 ======-----







BusyBox v1.24.1 (2015-11-07 13:44:45 CET) built-in shell (ash)


TOPF:~# export PS1='MAT:\w# '
MAT:~# KEY by code: 160 - OK/LIST
**** 5004 4 ****
[SEM] UP
KEY_PRESS - 160 4
++++ 0 ms ++++
playing 4097:0:0:0:0:0:0:0:0:0:/media/net/FritzNAS_Musik/!Playlist/01 - A-ha - Take On Me.mp3
[servicelist] search for service in userbouquets
KEY by code: 160 - OK/LIST
**** 51 4 ****
++++ 71 ms ++++
KEY_RELEASE - 160 00 4 4 CAUSE=Timeout
---- 124 ms ----
[SEM] DOWN
[servicelist] service not found in any userbouquets
< 148.905609> [eServiceMP3] construct!
< 148.942930> [eServiceMP3] playbin uri=file:///media/net/FritzNAS_Musik/!Playlist/01%20-%20A-ha%20-%20Take%20On%20Me.mp3
< 149.510221> [eServiceMP3] starting pipeline
resolved to PLAY
< 149.840300> [eServiceMP3] gst_element_query_position failed in getPlayPosition
resolved to PLAY
< 149.858374> [eServiceMP3] gst_element_query_position failed in getPlayPosition
resolved to PLAY
< 149.891559> [eServiceMP3] gst_element_query_position failed in getPlayPosition
RemovePopup, id = ZapError
resolved to PLAY

[rantanplan]

Ne dann ist es nicht übernommen worden...

Die Version wird laufen, da der verwendete gst eben noch ne andere Version ist.

die pyo wirklich gelöscht?
Neustart gemacht? nicht nur gui, sondern Receiver Neustart!
Dann müsste die Umleitung noch wo anders gewesen sein...

- - - Aktualisiert - - -

Du spielst die Datei via Bmediacenter ab?

[Alex23]

Ja.
- py rüberkopiert
- pyo gelöscht
- richtiger neustart

Nicht aufgenommene Filme (mp4,...) werden aber vorher als auch nachher mit 4099 abgespiel. Nur mp3s nicht.

- - - Aktualisiert - - -

Beides probiert (BMC und Aufnahme-Browser).

[bonkel]

das liegt dann daran, dass das system in der binary entscheidet und nicht die py....
und im c source ist angegeben welche file endung mit was abgespielt wird
im bs konnte ich das nur ändern, weil ich da den service eintragen kann...mp3 werden so nich abgespielt/aufgerufen
das problem liegt ja 100% an gst, ich hab zur zeit mit mips aber viel um die ohren.....

wenn ich das fertig hab, schaue ich mir das bauen für sh4 nochmal an und versuche gst upzudaten.

[Alex23]

Ok, das ist doch mal eine Aussage die hier allen weiter hilft.
Also geht eine Umleitung definitiv nicht. Da brauchen wir hier jetzt auch keine weiteren Experimente machen.

@bonkel: Wollte ja auch keinen Stress machen. Arbeite deine Agenda in Ruhe ab. Ich habe mit 14258 ja ein super funktionierendes Image. Wenn es etwas zu testen gibt und ich hier drauf aufmerksam werde, dann mach ich das.

@rantanplan: Danke für deine Hilfe und deine Mühe. Ich hätte nicht gewusst, wo ich etwas ändern muss, um die Wiedergabe umzuleiten. Ich hatte versucht mir die MC_AudioPlayer.pyo anzuschauen und mich ein wenig mit Python zu beschäftigen. Aber ohne die .py bringt das ja alles nichts.

[TheChip]

Ich bin selber Verfechter vom FFM. Bei den SH4 damals noch mehr, als jetzt mit dem Mips. Wir hatten damals ne "Weiche" in den Mix Images drin, mir denen entschieden wurde, was mit ffm und was mit gst abgespielt wurde. Da ich aber selber keine SH4 mehr hab, bin ich da nicht mehr im Bilde, ob die so noch funktioniert, was aber wahrscheinlich nicht der Fall ist.

[ReWard]

Stimmt. Ich meine das wäre auch bei sh4 gewesen, finde das aber nicht mehr.

Mp3 läuft bei mir aber, UFS 913, sh4, nur flac nicht, das ging aber glaube mal.

[rantanplan]

pyo kann man nach py auflösen
hier mal die vom MC_audioplayer abgeändert auf 4099
14601

- - - Aktualisiert - - -

Irgendwie ist der switch seit einiger Zeit im sh4 anders gemanaged.

Kleines Dilemma...
Serviceapp wäre jetzt die nächste eventuelle Lösung. Etwas verrückt, da ja eben diese Funktion an und für sich ewig im Image war.

[Alex23]

Danke für deinen Einsatz.
Ich habe es jetzt spaßeshalber mal getestet. Aber, wie erwartet, werden die mp3s mit 4097 wiedergegeben. Warten wir halt bis bonkel den gst upgedatet hat.
Von dem anderen Zeug (Weiche, Switch, Serviceapp, ...) hab ich leider (noch) keine Ahnung und kann daher auch keine qualifizierte Aussage dazu machen.
Ich habe mir aber einen Decompiler installiert. Falls ich Zeit habe, befasse ich mich mit dem Thema Python näher. Wobei ich nicht weiß, ob die AGB von HDMU Reverse-Engineering erlauben.