So, habe mir das jetzt nochmal angeschaut, wieder den gleichen Fehler gehabt und dann nochmal getestet. Bei meinen Kanälen wird die sref nicht abgeschnitten. Ich habe dann testweise den Sender nochmal per Plugin eingefügt und den Sendernamen angepasst (Namen der Server-Box entfernt)

#SERVICE 1:256:19:88:E:85:C00000:0:0:0:rtsp%3a//XXXXXX%3aXXXXXX@XXXXXX%3a554/stream?ref=1%3a0%3a19%3a88%3aE%3a85%3aC00000%3a0%3a0%3a0%3a:TNT Comedy HD
#DESCRIPTION TNT Comedy HD

-> 400 Bad Request, da die an timerAdd übergebene sref sowohl Url, als auch Sendernamen mit Leerzeichen enthält.

#SERVICE 1:256:19:88:E:85:C00000:0:0:0:http%3a//XXXXXX%3aXXXXXX@10.8.0.1%3a8001/1%3a256%3a19%3a88%3aE%3a85%3aC00000%3a0%3a0%3a0%3a:TNT Comedy HD
#DESCRIPTION TNT Comedy HD

-> Funktioniert ohne Probleme

Ich kann allerdings - bis auf die Url - keinen Unterschied erkennen. Da meine Client-Box per VPN über das Internet mit meiner Server-Box verbunden ist, reicht die Bandbreite für Variante 2 leider nicht aus - daher benutze ich den rtsp-Server.

Ich teste mal etwas weiter, warum sich der RemoteTimer mit rtsp-Url anders verhält als mit httpUrl.

Ich bin frühestens Montag wieder an der Box, um das nachzustellen, kann das dann aber natürlich machen. Was ich Dir aber schon sagen kann: Bei mir wird bei getServiceUrl nichts abgeschnitten, sondern die komplette sref inkl. Url und Name zurück gegeben.

Wenn an die Server-Box allerdings nur die abgeschnittene Variante übergeben werden soll (was ja eigentlich auch Sinn macht, wenn ich jetzt mal drüber nachdenke - wofür braucht der Server auch die Url :), dann wäre mein Patch am Ende der folgenden Seite ausreichend: Reconnectfunktion bei Bouquet Streams
Zumindest für den Weg über die Info-Taste.

Das Problem hatte ich schon, als noch NN2 auf der Client-Box lief und jetzt immernoch mit dem DMM-Image.

Komisch, dass die sref bei Dir automatisch abgeschnitten wird. Aber zumindest der "split-patch" schadet ja definitiv nicht, wenn Du ihn überall einbaust, wo timerAdd aufgerufen wird. Die anderen Stellen sind ja dann eh unnötig, da die von drr Server-Box ausgelesenen Timer dann keine Sonderzeichen enthalten können.

Bin nicht an der Box, da unterwegs. Aber ich habe, glaube ich, einfach auf die Info-Taste gedrückt, um zur Sendungsinfo zu gelangen, dort dann auf grün (Timer setzen) und ohne Änderungen vorzunehmen (es war automatisch der Remote-Timer gewählt) den Timer gesetzt.

Auf die Idee, dass man die container als service ref darstellt, bin ich noch gar nicht gekommen. Ich habe erst vor kurzem angefangen mich mit Enigma2-Receivern zu beschäftigen und bin noch lange nicht mit allem vertraut. Werde mir aber die Debug-Ausgaben auf jeden Fall demnächst mal ansehen. Danke für den Tipp!

Ah ok, das ist super!
Wenn Interesse seitens der User besteht, kann ich gern meine .debs für die Zeit bis zum Release des neuen Servers hier hochladen?! Schaffe ich aber micht vor Montag - bin unterwegs.

@Ghost: Ein Killer-Feature wäre übrigens, wenn man dem rtsp-Server nicht nur srefs als Parameter übergeben kann, sondern auch Datei-Pfade zu lokalen Aufnahmen/Filmen. Ich habe nämlich auf meiner Server-Box einige Filme liegen, die zu gross zum direkten Streamen sind (zu wenig Bandbreite). Die muss ich mir immer entweder vor dem schauen au die Client-Box kopieren oder über das Webinterface den Film auf der Server-Box starten, den rtsp-Server auf Live-TV stellen und darüber streamen. Wenn man in der Url direkt einen Dateinamen zum abspielen übergeben könnte, würde das die Sache extrem vereinfachen. Ist etwas in dieser Richtung geplant?

Ich habe z.B. folgenden Sender in meinem Bouquet. Dieser wurde mit Partnerbox angelegt und ich habe lediglich die URL auf die rtsp-Variante geändert:

#SERVICE 1:256:19:EF10:421:1:C00000:0:0:0:rtsp%3a//XXXXXX%3XXXXXX@XXXXXX%3a554/stream?ref=1%3a0%3a19%3aEF10%3a421%3a1%3aC00000%3a0%3a0%3a0%3a:RTL HD
#DESCRIPTION RTL HD

Legt man auf der Client-Box einen Remote-Timer an, erhält man als Fehlermeldung: 400 Bad Request

Das journal sieht dann so aus:

Feb 07 16:40:25 dm520 enigma2[629]: action ->  SetupActions save
Feb 07 16:40:25 dm520 enigma2[629]: [Connector] - Running command  http://10.8.0.1:80/web/session
Feb 07 16:40:25 dm520 enigma2[629]: [Connector] - Read sessionId
Feb 07 16:40:25 dm520 enigma2[629]: [Partnerbox] - got session
Feb 07 16:40:25 dm520 enigma2[629]: [Connector] - Running command  http://10.8.0.1:80/web/timeradd?sRef=1:256:19:EF10:421:1:C00000:0:0:0:rtsp%3a//XXXXXX%3aXXXXXX@XXXXXX%3a554/stream?ref=1%3a0%3a19%3aEF10%3a421%3a1%3aC00000%3a0%3a0%3a0%3a:RTL HD&begin=1518015600&end=1518019200&name=Verdachtsf%C3%A4lle&description=Verdachtsf%C3%A4lle&dirname=/media/hdd/movie/&tags=None&eit=3364&justplay=0&afterevent=3&repeated=0
Feb 07 16:40:26 dm520 enigma2[629]: [Connector] - Error in runCommand [Failure instance: Traceback (failure with no frames): <class 'twisted.web.error.Error'>: 400 Bad Request
Feb 07 16:40:26 dm520 enigma2[629]: ]
Feb 07 16:40:26 dm520 enigma2[629]: [Partnerbox] - Error in sendPartnerBoxWebCommand 400 Bad Request
Feb 07 16:40:26 dm520 enigma2[629]: [Partnerbox] - Error in getSessionId [Failure instance: Traceback (failure with no frames): <class 'twisted.web.error.Error'>: 400 Bad Request
Feb 07 16:40:26 dm520 enigma2[629]: ]

Das liegt daran, dass die URL falsch aufgebaut ist ("RTL HD" statt "RTL%20HD").

Ich habe dann in RemoteTimerEntry.py ein urllib.quote() um die sref gepackt. Danach funktioniert das Anlegen des Timers:

Feb 07 17:00:22 dm520 enigma2[562]: action ->  SetupActions save
Feb 07 17:00:22 dm520 enigma2[562]: [Connector] - Running command  http://10.8.0.1:80/web/session
Feb 07 17:00:22 dm520 enigma2[562]: [Connector] - Read sessionId
Feb 07 17:00:22 dm520 enigma2[562]: [Partnerbox] - got session
Feb 07 17:00:22 dm520 enigma2[562]: [Connector] - Running command  http://10.8.0.1:80/web/timeradd?sRef=1%3A256%3A19%3AEF10%3A421%3A1%3AC00000%3A0%3A0%3A0%3Artsp%253a//XXXXXX%253aXXXXXX%40XXXXXX%253a554/stream%3Fref%3D1%253a0%253a19%253aEF10%253a421%253a1%253aC00000%253a0%253a0%253a0%253a%3ARTL%20HD&begin=1518019200&end=1518021000&name=Betrugsf%C3%A4lle&description=Betrugsf%C3%A4lle&dirname=/media/hdd/movie/&tags=None&eit=3424&justplay=0&afterevent=3&repeated=0
Feb 07 17:00:23 dm520 enigma2[562]: create buffer for widget 600 x 200

Ich bekam jedoch auch einen 400 Bad Request beim Versuch die Remote Timer Liste zu öffnen und den angelegten Timer wieder zu löschen. Da wurde dann wieder die sref nicht encoded.

Ich habe daraufhin alle *.py durchsucht und die entsprechenden Stellen geändert. Patch im Anhang des Posts.

Client-Box hat original unstable DMM-Image - Serverbox läuft mit NN2

Habe heute mal ein bisschen Zeit zum debuggen und testen gehabt und dabei auch gstreamer inkl. plugins etc. auf 1.12.4 geupdated.
Das Problem tritt auch mit gstreamer 1.12.4 auf und scheint ein deadlock Problem zu sein.

Und zwar erfolgt in dreamrtspserver.c in der Funktion tsmux_pad_probe_unlink_cb() in Zeile 2379 ein Aufruf von gst_element_set_state (), der unter bestimmten Voraussetzungen nie beendet wird.

Ich habe die ganze if-Abfrage testweise mal durch folgenden Code ersetzt:

gst_element_call_async(source, (GstElementCallAsyncFunc) gst_element_set_state, (gpointer *)((GstState) GST_STATE_NULL), NULL);

Und voila... Keine Hänger mehr. Ich kann wild hin und her zappen und der dreamrtspserver läuft super durch

Es gibt noch mehrere Stellen, an denen gst_element_set_state aufgerufen wird. Die habe ich zwar jetzt nicht angefasst - aber theoretisch muss jede Stelle angepasst werden, die auf ein element zugreift, auf das auch ein anderer Thread zur gleichen Zeit zugreifen könnte.

Leider wurde der commit, der gst_element_call_async enthält (https://lists.freedesktop.org/…ts/2016-April/093926.html) erst in Version 1.9.1 aufgenommen. Keine Ahnung, ob das jetzt ein Backport auf 1.6.4 wird oder gstreamer und was noch alles so dazugehört ein Update erhält - aber ich würde mich freuen, wenn ich bald wieder gstreamer und dreamrtspserver vom Feed laufen lassen kann und meine "Frickel-Version", die zwar bis jetzt gut funktioniert, aber nicht alle Features enthält (hatte z.B. keine Lust den udpsrc IGMPv3 patch anzupassen und habe den und andere einfach weggelassen), in Rente schicken kann.

Wenn genannte WARN-Meldung ausgegeben wird, wurde die Funktion aufgerufen durch Zeile 1021 in gstdreamvideosource.c.
Aber selbst wenn man dort state = READTRREADSTATE__STOP setzt, falls gst_clock_get_internal_timeden Wert 0 zurückgegeben hat, wird die while Schleife zwar verlassen - aber der rtsp-Server hängt immer noch und neue Verbindungen werden nicht vernünftig bedient.

Hallo,

ich schaue von meiner Client-Box (dm525) die meisten Sender als transkodierte Streams, die von meiner Server-Box (dm820) kommen. Das funktioniert im Normalfall super. Leider hängt sich der dreamrtspserver beim zappen immer wieder mal auf. Das monitore ich zwar mit einem Script (wenn er sich aufhängt, gibt es Verbindungen mit Status CLOSE_WAIT und ich starte den Service einfach neu), aber man muss immer ein paar Sek warten und hin und her zappen, bis die Client-Box wieder ein Bild bekommt.

Jedenfalls nervt mich das so sehr, dass ich mal auf Fehlersuche gegangen bin.

Das Problem entsteht wie folgt:

1. Client zappt zu anderem Kanal
2. Neue Verbindung zu RTSP-Server wird aufgebaut und die alte geschlossen.
3. Bei jedem 10. bis 20. Zap liefert der RTSP-Server auf einmal kein Bild mehr und schreibt auch gar nichts mehr ins journal. Die neue Verbindung kam aber noch zustande und die alte wurde korrekt geschlossen.
4. Der Client zappt weiter, weil ja kein Bild kam.
5. Eine neue Verbindung wird zwar aufgebaut, aber keine Daten werden gesendet. Die alte Verbindung bleibt mit CLOSE_WAIT offen.

Per GST_DEBUG env kann man im WARN-Level sehen, dass ab Zeitpunkt "3." immer wieder folgende Meldung gesendet wird. Habe zwar mal in den Code von gst-plugin-dreamsource gesehen, aber mir den Quellcode der anderen Projekte noch nicht genau angesehen und zurück verfolgt, wo genau die aufrufende Schleife sich befindet, aber es scheint so, als wenn der dreamrtspserver in einer Schleife versucht einen Zeitwert aus einem Stream, der vorher anscheinend nicht korrekt geöffnet wurde, zu lesen. Da das nicht funktioniert, hängt der Server hier fest und bearbeitet auch weitere Anfragen nicht richtig.

0:00:45.387926747 13205 0x75d06e60 WARN        dreamsourceclock gstdreamsource.c:118:gst_dreamsource_clock_get_internal_time:<GstDreamAudioSourceClock> can't ENC_GET_STC error: Inappropriate ioctl for device, fd=13, ret=-1

Aber mal zurück zum Thema. Bei mir reconnected der Stream nicht, trotzdem ich jetzt mal testweise die 256 in die SRef eingebaut habe. Ich kann zwar das Netzwerkkabel ziehen und wenn ich es wieder einstecke läuft der Stream weiter - aber starte ich einfach auf der Server-Box den rtsp-Server neu, dann bricht die Wiedergabe ab und startet nicht neu. Habe NN2 laufen - aber das sollte ja eigentlich keinen Unterschied machen, oder?

Ich habe es im Moment noch mit Portforwarding laufen und den RTSP mit User/Pass versehen. Eine VPN Verbindung habe ich zwar zwischen den Boxen, die schluckt aber zuviel Overhead und CPU-Last, daher lasse ich die Streams unverschlüsselt übertragen und mache nur alles restliche per VPN.

Besser wäre es natürlich den Port 554 nicht öffentlich freigeben zu müssen. Wenn Du Lust auf rumbasteln hast, mache das am besten über einen SSH-Tunnel und benutze den Cipher arcfour. Der ist zwar schnell und leicht knackbar (man kann also mitlesen was Du da an Daten transferierst), aber Du hast weniger Chance, dass jemand Deine Box hackt, für den Fall dass bspw. im dreamrtspserver ein Bufferoverflow ist und man Code injecten kann. Dazu musst Du dropbear durch openssh ersetzen und den arcfour Cipher in der sshd_config erlauben. Anmerkung: Das Verfahren zur Authentification wird nicht beeinträchtigt, nur weil man arcfour benutzt - der Login ist also immer noch sicher, nur die übertragenen Daten sind leichter sichtbar. Das funktioniert grundsätzlich gut - habe zum Beispiel mein movie-Verzeichnis der Server-Box per sshfs mit arcfour auf meiner Client-Box gemountet. Der Datendurchsatz ist super und kein Vergleich zu einem anderen Cipher oder NFS über VPN. Habe nur noch keine Lust gehabt autossh für mipsel zu compilieren und die Stream-URLs nochmals zu ändern

Die Bouquets habe ich einfach vom Partnerbox-Plugin anlegen lassen und dann in den userbouquet Dateien die URLs ersetzt. Sieht jetzt bei mir bspw. so aus:

#SERVICE 1:0:1:2F30:441:1:C00000:0:0:0:rtsp%3a//USER%3PASS@DOMAIN%3a554/stream?ref=1%3a0%3a1%3a2F30%3a441%3a1%3aC00000%3a0%3a0%3a0%3a:RTLplus
#DESCRIPTION RTLplus

Das Partnerbox-Plugin habe ich immer noch laufen für die RemoteTimer. Das hat aber ein Problem mit Sendern, die ein Leerzeichen im Namen haben. Dafür habe ich auch einen Fix, aber bisher noch nicht die Muße gehabt mich im Entwickler-Forum anzumelden und den zu posten. Aber vielleicht liest ja hier jemand mit :):

--- a/Partnerbox/RemoteTimerEntry.py
+++ b/Partnerbox/RemoteTimerEntry.py
@@ -543,6 +543,11 @@
                        except:
                                self.mode = "add"


+                       service_ref_arr = service_ref.split(':', 10)
+                       if len(service_ref_arr) == 11:
+                               service_ref_arr[10] = ''
+                               service_ref = ':' . join(service_ref_arr)
+
                        if self.mode == "add":
                                sCommand = "%s/web/timeradd?sRef=%s&begin=%d&end=%d&name=%s&description=%s&dirname=%s&tags=%s&eit=%s&justplay=%d&afterevent=%s&repeated=%d" % (http, service_ref,begin,end,urllib.quote(name),urllib.quote(descr),urllib.quote(dirname),urllib.quote(self.timerentry_tagsset.value), self.timer.eit, justplay,afterevent, self.timer.repeated)
                        else: # edit

Nein das Script läuft bei mir dauerhaft als service. Kannst Du aber auch per cron ausführen, dann aber das "while true", "do", "sleep 2" und "done" entfernen.

Per Cron hst Du aber das Problem, dass Du eine Minute bis zum "Fix" warten musst. Als Service läuft es in einer Endlosschleife und prüft den Status alle 2 Sekunden. Somit brauche ich eigentlich nur kurz hin und herschalten und kann sofort wieder gucken.

Ich habe eine 820HD als Server-Box.

#!/bin/bash


while true
do
    TEST=`/bin/netstat -apn | /bin/grep dreamrtsps | /bin/grep -v grep | /bin/grep CLOSE_WAIT`


    if [ -n "$TEST" ] ; then
        /bin/systemctl restart dreamrtspserver.service
    fi


    TEST=`/bin/netstat -apn | /bin/grep dreamrtsps | /bin/grep -c ESTABLISHED`


    if [ "$TEST" -ne "0" -a "$TEST" -ne "1" ] ; then
        /bin/systemctl restart dreamrtspserver.service
    fi


    sleep 2
done

Testet erstens auf das angesprochene CLOSE_WAIT-Problem (passiert oft) und zweitens, ob mehr als ein Stream besteht. Das letztere macht erstens meine Bandbreite nicht mit und zweitens lockt die erste Verbindung den Sender und die zusätzlichen Streams können nicht mehr per ?ref umschalten (passiert nur sporadisch ganz selten)

Oh sorry - wusste nicht, dass NN etwas eigenes für Picons benutzt. Werde dort nachfragen!

Komisch. Aber hier am Beispiel von RTLplus:

root@dm520:~$ cat /etc/enigma2/userbouquet.favourites.tv | grep RTLplus
#SERVICE 1:0:1:2F30:441:1:C00000:0:0:0:rtsp%3a//USER%3PASS@DOMAIN%3a554/stream?ref=1%3a0%3a1%3a2F30%3a441%3a1%3aC00000%3a0%3a0%3a0%3a:RTLplus
#DESCRIPTION RTLplus

Passende Picons sind auch da:

root@dm520:~$ find /picons/ -name `cat /etc/enigma2/userbouquet.favourites.tv | grep RTLplus | grep SERVICE | awk '{print $2}' | cut -d':' -f1-10 | sed 's/:/_/g'`*
/picons/piconlcd/1_0_1_2F30_441_1_C00000_0_0_0.png
/picons/piconHD/1_0_1_2F30_441_1_C00000_0_0_0.png

Mit dieser Service-Ref und diesen Picons funktioniert es auf meiner Server-Box sowohl in Programmliste, als auch in der Infobar und LCD. Auf der Client-Box fehlt das Picon in der Info-Bar, während es in der Programmliste angezeigt wird.

Gesucht werden laut Log auch nur folgende Picons:

root@dm520:~$ journalctl | grep 2F30_441_1_C00000
Jan 29 10:15:09 dm520 enigma2[200]: [PiconLoader] Searching: /picons/piconSList/1_0_1_2F30_441_1_C00000_0_0_0_rtsp%3a//USER%3PASS@DOMAIN%3a554/stream?ref=1%3a0%3a1%3a2F30%3a441%3a1%3aC00000%3a0%3a0%3a0%3a.png
Jan 29 10:15:09 dm520 enigma2[200]: [PiconLoader] Searching: /picons/piconSList/1_0_1_2F30_441_1_C00000_0_0_0.png

Picon ist auch wie gesagt da:

root@dm520:~$ ls /picons/piconSList/1_0_1_2F30_441_1_C00000_0_0_0.png -l
-rw-r--r--    1 root     root          3176 Dec  4 09:47 /picons/piconSList/1_0_1_2F30_441_1_C00000_0_0_0.png

Ich benutze den original-Skin. Und mit diesem funktioniert es auf der Server-Box - nur eben nicht auf der Client-Box.
Bei den Kanälen, die meine Freundin selbst empfangen kann, funktionieren die Picons auch. Nur eben nicht bei denen, die gestreamed werden. Service-Refs passen aber wie gesagt, da die richtigen Picons in der Senderübersicht dargestellt werden. Nr eben nicht in der Info-Bar...

Das Problem ist, dass dann die Service-Refs in der lamedb nicht mehr zu denen iM Bouqet passen. Und nur wenn die passen, wird das EPG richtig importiert.

Bei gestreamten Sendern, werden Picons nicht in der Infobar angezeigt. Die Service-Refs sind aber definitiv richtig, da ich die original refs der Server-Box verwende und sowohl EpgImporter funktioniert, als auch Picons in der Senderübersicht richtig angezeigt werden. Nur in der Infobar fehlen sie. Die Picons sind auch definitiv im richigen Format, da ich sie selben Picons auf meiner Server-Box verwende und sie dort in der Infobar angezeigt werden.

Ich würde mir wünschen, dass es automatische Reconnects gibt, wenn beim Öffnen von Streams keine Verbindung hergestellt werden kann und es so lange immer wirder probiert wird, bis der Stream läuft.
Ich streame nämlich sehr viele Sender von meiner Sat-Box zuhause zu meiner Client-Box, dir bei meiner Freundin steht, über das Internet. Das geht aufgrund der Bandbreite nur per rtsp. Dummerweise schließt der dreamrtspserver immer mal wieder Verbindungen nicht richtig beim Umschalten. Die haben dann den Status CLOSE_WAIT. Erst wenn man den dreamrtspserver neustartet, kann ein anderer Stream geöffnet werden. Um das zu Lösen überprüft ein Script auf der Server-Box einmal pro Sekunde die offenen Verbindungen und restartet den rtspserver, wenn CLOSE_WAIT gefunden wird. Jedenfalls muss muss ich in dem Fall immer auf einen anderen Sender und wieder zurück wechseln, weil es keinen automatischen erneuten Verbindungsversuch gibt.
Bitte macht das nicht von Änderungen in der Service-Ref abhängig. Damit nämlich alle Kanäle in der lamedb enthalten sind und der EpgImporter funktioniert, kopiere ich auf die Client-Box die lamedb der Server-Box und mache dann einen Sendersuchlauf. So habe ich auch die Sat-Sender in der lamedb und benutze die Original Service-Refs in den Bouquets. Das ist auch für die Picons sehr nützlich, die kann ich nämlich auch einfach von der Server-Box auf die Client-Box kopieren und es läuft.

Ja, da habe ich noch keine Beeinträchtigung festgestellt. Ich habe auch testweise ohne Probleme per "Rec"-Button eine Aufnahme gestartet, 5 Minuten gewartet, diese Aufnahme abgespielt während noch weiter aufgenommen wird und über 30 Minuten ohne Unterbrechung schauen können. Ist ja quasi ähnlich zu Timeshift.
Nur wenn ich per Start/Stop-Taste das echte Timeshift aktiviere, kurz warte und dann abspiele, hängt die Wiedergabe nach einiger Zeit. Mal kann man 5 Minuten gucken, mal hängt sie direkt nach 1 Minute.

Nehme ich Videos manuell auf und schaue mir sie an während die Aufnahme noch läuft, sieht das Log so aus:

Jan 28 07:01:49 dm520 enigma2[3217]: getNextSourceSpan, current offset is 2275396900, m_skipmode_m = 0!
Jan 28 07:01:49 dm520 enigma2[3217]: NO CUESHEET. (2275396900, 10485700)
Jan 28 07:01:50 dm520 enigma2[3217]: PTS         2643794e found at 2385378592 pid 41 stream: c0
Jan 28 07:01:52 dm520 enigma2[3217]: PTS         2645fe4e found at 2386888044 pid 41 stream: c0
Jan 28 07:01:54 dm520 enigma2[3217]: PTS         264902ce found at 2388665772 pid 41 stream: c0
Jan 28 07:01:56 dm520 enigma2[3217]: PTS         264be94e found at 2390356644 pid 41 stream: c0
Jan 28 07:01:58 dm520 enigma2[3217]: PCR         264e953e found at 2391892604 pid 42 (47 40 42 30 07 10 13 27 4b 9f 7e)
Jan 28 07:02:00 dm520 enigma2[3217]: no cue sheet. forcing normal play
Jan 28 07:02:00 dm520 enigma2[3217]: PTS         2651204e found at 2393441724 pid 41 stream: c0
Jan 28 07:02:02 dm520 enigma2[3217]: getNextSourceSpan, current offset is 2285882600, m_skipmode_m = 0!
Jan 28 07:02:02 dm520 enigma2[3217]: NO CUESHEET. (2285882600, 10485700)
Jan 28 07:02:02 dm520 enigma2[3217]: PTS         2653c34e found at 2394991032 pid 41 stream: c0
Jan 28 07:02:04 dm520 enigma2[3217]: PTS         2656c04e found at 2396705404 pid 41 stream: c0
Jan 28 07:02:06 dm520 enigma2[3217]: PTS         2659634e found at 2398267308 pid 41 stream: c0
Jan 28 07:02:08 dm520 enigma2[3217]: PTS         265c49ce found at 2400000668 pid 41 stream: c0
Jan 28 07:02:10 dm520 enigma2[3217]: PTS         265eecce found at 2401552232 pid 41 stream: c0
Jan 28 07:02:12 dm520 enigma2[3217]: PTS         26618fce found at 2403064692 pid 41 stream: c0
Jan 28 07:02:13 dm520 enigma2[3217]: no cue sheet. forcing normal play
Jan 28 07:02:14 dm520 enigma2[3217]: PTS         2664854e found at 2404817228 pid 41 stream: c0

usw.

Bei Timeshift sieht es so aus:

Jan 28 07:09:01 dm520 enigma2[3217]: getNextSourceSpan, current offset is 178256900, m_skipmode_m = 0!
Jan 28 07:09:01 dm520 enigma2[3217]: NO CUESHEET. (178256900, 10485700)
Jan 28 07:09:12 dm520 enigma2[3217]: no cue sheet. forcing normal play
Jan 28 07:09:14 dm520 enigma2[3217]: getNextSourceSpan, current offset is 188742600, m_skipmode_m = 0!
Jan 28 07:09:14 dm520 enigma2[3217]: NO CUESHEET. (188742600, 10485700)
Jan 28 07:09:16 dm520 enigma2[3217]: It's now  So 28 Jan 2018 07:09:16 CET
Jan 28 07:09:16 dm520 enigma2[3217]: [timer.py] next activation: 1517119856 (in 99999 ms)
Jan 28 07:09:25 dm520 enigma2[3217]: no cue sheet. forcing normal play
Jan 28 07:09:27 dm520 enigma2[3217]: getNextSourceSpan, current offset is 199228300, m_skipmode_m = 0!
Jan 28 07:09:27 dm520 enigma2[3217]: NO CUESHEET. (199228300, 10485700)
Jan 28 07:09:36 dm520 enigma2[3217]: wait for driver eof ok
Jan 28 07:09:36 dm520 enigma2[3217]: reached EOF, but we are in stream mode. delaying 1 second.
Jan 28 07:09:36 dm520 enigma2[3217]: eDVBChannel: End of file!
Jan 28 07:09:36 dm520 enigma2[3217]: eDVBServicePlay::pause

Kurios finde ich auch, dass die Fehlermeldung immer ein 1 Sekunden Delay angibt, aber der Status noch in der selben Sekunde auf "Pause" geändert wird.