MP3 werden in 7.0 und 6.4 mit Fehlern abgespielt
- Makumbo
- VIP
- Beiträge: 1508
- Registriert: 13 Mär 2016 07:42
- Receiver 1: Vu+ DUO 4K mit 7.5.1
- Hat gedankt: 757 Mal
- Hat Dank erhalten: 574 Mal
Knackser, Hickser, Aussetzer - egal, irgenwas stimmt da nicht.
Während es bei @jogibär immer bei 2:00 bis 2:30 ist, ist es bei mir
fast immer genau bei 3:40, machmal 2 oder 3 Sekunden später - Test mit mehreren mp3 Files.
Das bekräftig mich nochmal in meiner Vermutung, dass es da, je nach Box, einen xxx Bytes großen Cache gibt.
Und wenn der leer ist, wird er erstmal wieder gefüllt.
Und das führt zur "Störung".
Kann doch sein, oder?
Gruß - Makumbo
Während es bei @jogibär immer bei 2:00 bis 2:30 ist, ist es bei mir
fast immer genau bei 3:40, machmal 2 oder 3 Sekunden später - Test mit mehreren mp3 Files.
Das bekräftig mich nochmal in meiner Vermutung, dass es da, je nach Box, einen xxx Bytes großen Cache gibt.
Und wenn der leer ist, wird er erstmal wieder gefüllt.
Und das führt zur "Störung".
Kann doch sein, oder?
Gruß - Makumbo
- Papi2000
- Super Moderator
- Beiträge: 26876
- Registriert: 20 Apr 2013 20:09
- Receiver 1: Viele GigaBlues
- Receiver 2: DM und ZGemma
- Receiver 3: bissl VU
- Hat gedankt: 4570 Mal
- Hat Dank erhalten: 8695 Mal
Da es mehreren Boxen, aber nicht 100% reproduzierbar auftritt, tippe ich mal eher auf ein Interruptproblem, bei dem irgendeine Hardware abgefragt wird, was halt meist mit Mainprio im Hauptzweig der Software abläuft. Wenn da etwas kurz hakt, dann sind die restlichen Prozesse solange ausgeknipst. Das kann LAN, USB, SATA, HDMI, etc. sein.
Dagegen spricht, dass es mit ein und denselben Treibern (die sind richtig hardwarenah) in unterschiedlichen Images mit ähnlichem MediaFrameWork (teamBlue und oATV setzen beide auf gstreamer integrated) beim teamBlue nicht auftritt.
Wenn man die unterschiedlichen Zeiten über derweil transportierte Datenmenge an einem Festwert aufhängen könnte, die dann wieder gleich wäre, wäre das Buffern im eingesetzten MediaFrameWork des Images ein Ansatz.
Auch im selben Image mit unterschiedlichen Playern (also Wechsel des MediaFrameWork) gibt es Abhilfe. Das wäre ein weiterer Aspekt für den Ansatz Buffer.
Und genau daran wird aktuell testweise im oATV ja geschraubt.
EDIT:
Da fällt mir im Zusammenhang mit Buffern und vor allem Speicherverwaltung ein wichtiger Punkt ein:
Cacheflush / Speicherbereinigung des RAM. Ich hatte mal mit clearmem rumgespielt, und dabei natürlich auch mal übertrieben kurze Clearzeiten (10s) eingestellt. Dabei konnte das Image den Speicher nicht mehr vernünftig nutzen. Das führte zu dauerndem Ruckeln bei Wiedergaben und sogar im LiveTV.
Dagegen spricht, dass es mit ein und denselben Treibern (die sind richtig hardwarenah) in unterschiedlichen Images mit ähnlichem MediaFrameWork (teamBlue und oATV setzen beide auf gstreamer integrated) beim teamBlue nicht auftritt.
Wenn man die unterschiedlichen Zeiten über derweil transportierte Datenmenge an einem Festwert aufhängen könnte, die dann wieder gleich wäre, wäre das Buffern im eingesetzten MediaFrameWork des Images ein Ansatz.
Auch im selben Image mit unterschiedlichen Playern (also Wechsel des MediaFrameWork) gibt es Abhilfe. Das wäre ein weiterer Aspekt für den Ansatz Buffer.
Und genau daran wird aktuell testweise im oATV ja geschraubt.
EDIT:
Da fällt mir im Zusammenhang mit Buffern und vor allem Speicherverwaltung ein wichtiger Punkt ein:
Cacheflush / Speicherbereinigung des RAM. Ich hatte mal mit clearmem rumgespielt, und dabei natürlich auch mal übertrieben kurze Clearzeiten (10s) eingestellt. Dabei konnte das Image den Speicher nicht mehr vernünftig nutzen. Das führte zu dauerndem Ruckeln bei Wiedergaben und sogar im LiveTV.
- Doctor Who
- VIP
- Beiträge: 4572
- Registriert: 11 Aug 2020 17:33
- Wohnort: OWL
- Receiver 1: AX HD51 4k HDF 7.5 + ATV 7.5.1
- Receiver 2: Zgemma H7S HDF7.3 + ATV 7.5.1
- Receiver 3: AXAS E4HD Ultra 4k
- Receiver 4: Intel NUC FNCML357 + Raspi 3b mit KODI 21.2 Omega
- Hat gedankt: 2411 Mal
- Hat Dank erhalten: 2630 Mal
- Kontaktdaten: