Jump to content

iPad streaming Problem


PTFE

Recommended Posts

Hab den Fehler gefunden.

 

Läuft bei mir jetzt Problemlos. Gestern Abend ca. 1:45 Std., heute über 2 Stunden getestet. Keine Abrüche!

Nachteil: Vielmehr als 1000kbit funktioniert nicht. Woran es liegt kann ich nicht sagen. Sobald "bufsize > 200k" wird es instabil...

Bei Actionszenen leider nicht so toll, dafür aber stabil!

 

Habe für mich nur 3 Profile zur Auswahl. Preset habe ich im Profil fest vorgegeben!

1200 kbit - im fremeden WLAN und Lokal oder kurz via 3G. Traffic liegt bei etwa 465MByte pro Stunde

 

500 kbit - Im 3G Netz. Traffic hab ich noch nicht genau gemessen. Liegt so zwischen 150 - 200 MByte pro Stunde

 

120 kbit - Qualität ist bescheiden, reicht soeben wenn nur Edge vorhanden ist.

 

[1200 kbit]
Cmd=-threads {threads} {offset} -i "{infile}" -f mpegts -c:v libx264 -crf 18 -maxrate 1200k -bufsize 200k {framerate} -map 0:0 -map 0:1 -filter:v yadif -vf "scale={scalex}:{scaley}" -preset fast -tune film -vprofile main -level 30 -c:a libvo_aacenc -b:a 128k -ar 48000 -ac 2 -af volume=2.000000 -y "{outfile}"
maxWidth_IPhone=960
maxHeight_IPhone=576	
maxWidth_IPad=960
maxHeight_IPad=576

[500 kbit]
Cmd=-threads {threads} {offset} -i "{infile}" -f mpegts -c:v libx264 -crf 22 -maxrate 450k -bufsize 200k {framerate} -map 0:0 -map 0:1 -filter:v yadif -vf "scale={scalex}:{scaley}" -preset fast -tune film -vprofile main -level 30 -c:a libvo_aacenc -b:a 48k -ar 48000 -ac 1 -af volume=2.000000 -y "{outfile}"
maxWidth_IPhone=592
maxHeight_IPhone=432
maxWidth_IPad=592
maxHeight_IPad=432

[120 kbit]
Cmd=-threads {threads} {offset} -i "{infile}" -f mpegts -c:v libx264 -crf 27 -maxrate 75k -bufsize 200k {framerate} -map 0:0 -map 0:1 -filter:v yadif -vf "scale={scalex}:{scaley}" -preset fast -tune film -vprofile main -level 30 -c:a libvo_aacenc -b:a 12k -ar 22050 -ac 1 -af volume=2.000000 -y "{outfile}"
maxWidth_IPhone=256
maxHeight_IPhone=160
maxWidth_IPad=256
maxHeight_IPad=160

Link to comment

Es scheint doch irgenwie am Recording Service zu liegen!!

Erstelle ich statt eines Streams ("{outfile}") eine Datei ("D:\ServerFolders\Videos\Aufnahmen\test.mp4") mit ansonst identischen Parametern, so gelangt dieser fehlerfrei auf der Festplatte. Dabei spielt es überhaupt keine Rolle wie groß der "Bufsize" gewählt wird.

 

Besipiel:

ffmpeg.exe -threads 0 -i "http://192.168.178.30:7522/upnp/channelstream/4.ts" -f mpegts -c:v libx264 -crf 18 -maxrate 1500k -bufsize 4000k -map 0:0 -map 0:1 -filter:v yadif -vf "scale=min(880\, trunc(iw/2)*2):trunc((ow/dar)/2)*2" -preset fast -tune film -vprofile main -level 30 -c:a libvo_aacenc -b:a 128k -ar 48000 -ac 2 -af volume=2.000000 -y "D:\ServerFolders\Videos\Aufnahmen\test.mp4"

Dabei wird ein Full-HD-Channel Live umgewandelt und Lokal auf die Festplatte gespeichert.

Hier sei angemerkt das Bufsize 4000k beträgt! Ein solcher Wert in der iphone.ini und ein Livestream schmiert in weinigen Sekunden ab!

 

WARUM?

 

Es liegt also NICHT an ffmpeg wie von Herrn Hackbart behauptet, sondern an der Verarbeitung bzw. Übergabe des Streams an den internen Segmenter!

Evtl. ein Pufferüberlauf?

 

Zur Info: Es findet die aktuelle Version von ffmpeg Verwendung!

Edited by epsy
Link to comment
  • 2 weeks later...

Ich habe übrigens Kontakt mit Lars_MQ aufgenommen (Entwickler des Recording Service).

Er hofft das Problem in seiner nächsten Version beheben zu können.

Das Problem liegt wohl in der Kommunikation zwischen ffmpeg Pipe output und dem Recoredings Service.

Unter gewissen Bedingungen kam es zu Pufferüberläufen.

Die neue Version will er zeitnah veröffentlichen, sofern nicht noch neue Probleme auftauchen.

Link to comment

Ich habe bereits eine neue Version getestet, die mit der aktuellsten ffmpeg Version auch nach Stunden noch streamt. Bis jetzt keine Ausfälle mehr gehabt...

Link to comment

Bin gespannt!

Helfe mir aktuelle mit einem Workaround, welches allerdings eine große Sicherheitslücke aufreißt!! Ausserdem funktioniert das Radiostreamen nicht und das Streamen von Aufnahmen ist eingeschränkt - man kan nicht sofort zu einer gewünschten Stelle springen.

Ein Vorteil bietet allerdings dieser Workaround: Man kann Zeitversetzt Live-TV schauen, sich beim Fussball eine Szene noch einmal ansehen...

 

live-tv.jpg

In diesem Beispiel kann man knapp 8,5 Minuten zurückspuelen, bzw. bei Werbung 2 Minuten überspringen.

Hat auch was.

UND: Es läuft zuverlässig.

Wegen der Sicherheistlücke ist diese Lösung aber leider nicht empfehlenswert! Ausserdem wird die Festplatte ständig benutzt. Lars Lösung nutzt lediglich Arbeitsspeicher!

Edited by epsy
Link to comment

Hi,

 

@epsy

 

wirklich toll wie du dich hier reinhängst um das Problem zu lösen.

und wirklich armselig wie die Entwickler mit dem Problem durch schweigen umgehen.

Hoffentlich behebt die nächste Version auch den Fehler, hat ja jetzt lange genug gedauert.

 

 

mfg stargate

Link to comment

und wirklich armselig wie die Entwickler mit dem Problem durch schweigen umgehen.

Hoffentlich behebt die nächste Version auch den Fehler, hat ja jetzt lange genug gedauert.

... und wirklich armselig, dass du nicht dazu im Stande bist, alle Beiträge zu lesen. Lars hat sich dem Problem angenommen und das iPhone/iPad Streaming überarbeitet. Ich konnte das auch bereits testen und keine Abbrüche mehr beobachtet. Ich habe jetzt schon einige Stunden mit dem aktuellsten ffmpeg Build hinter mir...

Link to comment

... und wirklich armselig, dass du nicht dazu im Stande bist, alle Beiträge zu lesen. Lars hat sich dem Problem angenommen und das iPhone/iPad Streaming überarbeitet. Ich konnte das auch bereits testen und keine Abbrüche mehr beobachtet. Ich habe jetzt schon einige Stunden mit dem aktuellsten ffmpeg Build hinter mir...

 

Naja, das Problem habe ich zum ersten mal am 18. August 2012 gemeldet und scheinbar besteht das Problem noch länger.. In diese Zeit bis jetzt ist das Problem bei etlichen Usern aufgetreten und es wurden auch einige Problemverursacher und Lösunsgmöglichkeiten von den Usern hier gepostet... von den Entwicklern kam keine Reaktion, nur eisiges schweigen.. Erst am 15 Jan 2013 kam von hackbart ne Reaktion, mir der Aussage es liegt nicht an uns... und scheinbar musste auch erst epsy aktiv auf Lars zugehen, damit sich überhaupt mal was bewegt...Wenn die User schon ihre Zeit dazu verwenden die Fehler der Entwickler zu finden, dann sollten die Entwickler sich auch mal in den entsprechenden Threads zu Wort melden.. Monatelanges schweigen ob an dem Problem überhaupt gearbeitet wird, kommt nicht gerade gut an, zumindest bei mir nicht.. und mindestens 5 potentiellen Kunden habe ich vom DVBViewer deswegen abgeraten und nach Vorführung des Problems, haben diese auch vom Kauf abgesehen..

 

mfg stargate

Link to comment

stargate: dein unproduktives genörgel motiviert die Entwickler mit Sicherheit besonders eine neue RS Version kurzfristig auch für die breite Masse bereitzustellen. Mit "armseelig" erreichst du glaube ich nicht Deine eigentliche Intention.

 

Um es mal auf den Punkt zu bringen: Danke an epsy für die Mühe, die Ursache für Lars soweit einzukreisen, dass wohl scheinbar eine Lösung gefunden wurde. Aus meiner eigenen Gerüchteküche hab ich noch erfahren, dass epsy Lars auch noch von Favoriten im RS überzeugen konnte :rotfl:

 

regards

Innu

Link to comment

Hi,

 

was heißt hier "unproduktives genörgel " das sind nunmal die Fakten. Immer nur alles schönreden macht es auch nicht besser. Ich habe mir durch mein "Genörgel" wie du es nennst auch nichts erhofft, ich wollte nur den Sachverhalt darstellen und dass die Politik des schweigens nicht gerade sehr förderlich ist.

 

MfG stargate

Link to comment

Hallo zusammen,

 

ich muss leider die anscheinend unendliche Geschichte streaming und iphone fortsetzen. Auch bei mir brach immer nach ner

Weile der stream ab. Heute zunächst frohlockt, denn die version 1.24 "soll" angeblich das Problem beheben. Tut sie aber bei

mir nicht. Mit dem neuesten ffmpeg - win64(22.2.13) läuft gar nichts. Er läd und läd...Die vorherige Version ffmpeg vom 8.1.13

führt zu wenigstens ein paar Minuten Stream Genuss. Und dann nach 4 Minuten, avi. datei aus otr, und nach 12 Minuten ts-datei

in sd, aufgenommen von DVBViewer da hängt es wieder :-(...Weiß jemand eine ffmpeg zu win64, die funzt? Ach ja, zdf hd läuft

gerade seit ca. 15 Minuten ohne Hänger.

 

Gruß

filmgucker

Link to comment

Die 64bit Versionen funktionieren bei mir auch nicht. Ich verwende die 32bit Version vom Freitag. Bisher läuft es hier einwandfrei. Habe aber noch nicht länger als 1 Stunde gestreamt. Vorher war nach ein paar Minuten Schluss.

 

Gruss

 

Rheinländer

Link to comment

Trotz 64Bit-Betriebssytem kann ein 32-Bit-ffmpeg verwendet werden. Da ich eine Wochenendveranstaltung hatte, konnte ich die aktuelle RS-Version nur kurz antesten. Ein Abbruch hab ich allerdings auch beim strammen von HD-Content verzeichnen müssen. Da ich übers Internet gestreamt habe - RS läuft bei mir zu Hause auf einem Heimserver und ich war im Büro - kann dies auch ein Problem der Internetverbinfung gewesen sein. Ein paralleler Download zwecks Update stockte nämlich ebenfalls...

Ein Test im heimischen Netzwerk blieb bisher aus.

Link to comment

Die 32bit Version von ffmpeg läuft problemlos unter Windows 64bit. Wie gesagt, ich konnte HD Sender fehlerfrei etwas mehr als eine Stunde aufs iPad streamen; dann habe ich manuell beendet. Ein Langzeittest (mehrere Stunden Streaming) konnte ich aus Zeitgründen noch nicht durchführen. Früher war aber bereits nach wenigen Minuten Schluss. Es sieht also gut aus.

 

Gruss

 

Rheinländer

Link to comment

Nach 2 Stunden uns 20 Minuten wurde ein HD-Stream unterbrochen - bekam ein Anruf ;)

Es läuft und zwar Perfekt!

Da bei die aktuelle 64-Bit-Version auch Probleme macht, habe ich die 64-Bit-Version vom 26.01. am laufen (N-49352-gc46943e)

 

Hinweis: hab auch die iphoneprefs.ini auf meine Bedürfnisse verändert!!

Link to comment

Mit dem neusten RS und der dort zum download angebotenen ffmpeg Version läuft es bei mir auch einwandfrei.

 

iphone4: 45min SD FTA

ipad4: 30min HD ÖR 720

ipad4: 30 min Sky HD 1080i

 

Alles ohne Unterbrechung. Längere Laufzeiten hatte ich jetzt keine Lust. :)

Angepasst habe ich nichts. Nur die Transcodier-Einstellungen auf "superfast" und die bitrate auf "high 1536 kbit" gestellt.

Bitrate dürfte je nach WLan und Transcodier-Einstellungen je nach CPU-Power keinen Unterschied machen.

Vom RS her scheint mir das jetzt perfekt zu funktionieren.

Link to comment

Jetzt klappt es wohl auch bei mir mit: ffmpeg 64 bit static vom 26.01.2013. Danke

noch mal, insbesondere für den Tipp mit der Version von ffmpeg 64bit. Es scheint

durchaus von der version der ffmpeg software abzuhängen, ob alles funktioniert.

 

Ich wünsche dann allen noch fröhliches Streamen und schnelle WLANs ;-)...

 

VG

filmguccker

Link to comment

Hallo zusammen,

 

ich habe mal den Thread verfolgt, da ich auch in letzter Zeit Probleme mit dem Streaming zum iPhone 5, bzw. iPad 4 habe... also, dass der Stream einfriert, bzw. stockt und dann weiterläuft. Unabhängg davon, ob ich über's heimische WLAN (FB 7390), im fremden WLAN, bzw. nur 3G streame.

 

Auf meinem PC (Win 7, 64 bit, leider nur DSL 16.000) läuft der aktuelle RS 1.24... beim Update habe ich die aktuellste FFmpeg mitinstallieren lassen. Welche Version habt Ihr am laufen und wie sind Eure Settings der Bitrate & Voreinstellungen bei den FFmpeg Varianten? Habt Ihr die Settings angepasst oder läuft es momentan mit den Voreinstellungen sauber (in welcher Kombi)?

 

 

Gruß, RSchally

Link to comment

Hi,

 

also scheinbar wurde das Problem jetzt behoben, bisher läuft bei mir auch alles wunderbar.

Ich experimentiere noch ne weile mit verschiedenen Einstellungen.

 

mfg stargate

Edited by stargate2k
Link to comment

Wie updatet Ihr ffmpeg korrekt?! Die .exe in den DVBViewer Ordner, alte überschreiben ist klar. Die Lizenzen, Presets auch mit kopieren/überschreiben?! Oder muss da noch mehr und in anderen Verzeichnissen aktualisiert werden?!

Welche Settings haben sich denn bei Euch für SD/HD im WLAN und welche für 3G bewährt?

 

Link to comment
[Lokal]

Cmd=-threads {threads} {offset} -i "{infile}" -f mpegts -c:v libx264 -crf 21 {framerate} -map 0:0 -map 0:1 -deinterlace -vf "scale={scalex}:{scaley}" -preset veryfast -tune film -vprofile main -level 3.1 -c:a libvo_aacenc -b:a 128k -ar 48000 -ac 2 -af volume=2.000000 -y "{outfile}"

maxWidth_IPhone=1136

maxHeight_IPhone=640

maxWidth_IPad=1280

maxHeight_IPad=720

 

[Mobil High - 1500kBit]

Cmd=-threads {threads} {offset} -i "{infile}" -f mpegts -c:v libx264 -crf 21 -maxrate 1250k -bufsize 900k {framerate} -map 0:0 -map 0:1 -deinterlace -vf "scale={scalex}:{scaley}" -preset veryfast -tune film -vprofile main -level 3.1 -c:a libvo_aacenc -b:a 128k -ar 48000 -ac 2 -af volume=2.000000 -y "{outfile}"

maxWidth_IPhone=1136

maxHeight_IPhone=640

maxWidth_IPad=1280

maxHeight_IPad=720

 

[Mobil Mid - 600bBit]

Cmd=-threads {threads} {offset} -i "{infile}" -f mpegts -c:v libx264 -crf 24 -maxrate 450k -bufsize 900k {framerate} -map 0:0 -map 0:1 -deinterlace -vf "scale={scalex}:{scaley}" -preset faster -tune film -vprofile main -level 3.1 -c:a libvo_aacenc -b:a 48k -ar 48000 -ac 1 -af volume=2.000000 -y "{outfile}"

maxWidth_IPhone=640

maxHeight_IPhone=480

maxWidth_IPad=640

maxHeight_IPad=480

 

[Mobil EEDGE - 120kBit]

Cmd=-threads {threads} {offset} -i "{infile}" -f mpegts -c:v libx264 -crf 27 -maxrate 70k -bufsize 900k {framerate} -map 0:0 -map 0:1 -deinterlace -vf "scale={scalex}:{scaley}" -preset faster -tune film -vprofile main -level 3.1 -c:a libvo_aacenc -b:a 10k -ar 22050 -ac 1 -af volume=2.000000 -y "{outfile}"

maxWidth_IPhone=256

maxHeight_IPhone=160

maxWidth_IPad=256

maxHeight_IPad=160

 

[AUDIO Stereo - 130kBit]

Cmd=-threads {threads} {offset} -i "{infile}" -f mpegts -vn -c:a libvo_aacenc -b:a 128k -ar 48000 -ac 2 -af volume=1.25 -y "{outfile}"

 

[Audio Mono - 64kBit]

Cmd=-threads {threads} {offset} -i "{infile}" -f mpegts -vn -c:a libvo_aacenc -b:a 48k -ar 48000 -ac 1 -af volume=1.25 -y "{outfile}"

 

Dem Aufmerksamen Leser wird es wundern, dass ich die alte Funktion "-deinterlace" statt "-vf yadif" verwende. Mir reicht die Qualität des alten Filters und dieser ist weniger rechenintensiv! Habe nur einen kleinen i3, un der ist bei HD-TV sonst überfordert ;)

 

Des weiteren habe ich mir erlaubt die Presets fest vorzugegeben. So lässt sich auf der letzten Seite die Auswahl ein wenig vereinfachen.

Statt Preset, 16:9, 4:3 etc. auszuwählen, kann man einfch auf einen Button klicken:

stream2.png

 

Hab ca. 1,8MBit upload, daher ein Profil mit knapp 1500kBit

 

ffmpeg updaten? einfach eine neue Version ins Verzeichnis kopieren. Behalte aber immer die alte Version!

 

FÜr SD und HD nutze ich die selben Einstellungen. Hab nur eine Kanalliste mit ca. 30 Programmen. Mehr schaue ich nicht. Eigentlich reichen mir 10 ;)

In dieser Liste sind HD und SD Programme gemischt aufgeführt.

 

Settings SD/HD im WLAN und welche für 3G bewährt?

Geht glaub ich aus den Namenspresets hervor! Wobei 1500kBit via 3G wenig zu empfehlen ist, da ca. 10MByte pro Minute übertragen werden - 550 - 600 MByte pro Stunde. Würde meinen freien Traffic von 1Gbyte schnell aufrauchen.

Aber in einem fremden WLAN wo Traffic keine Rolle spielt kann man in wirklich guter Qualität TV schauen.

Edited by epsy
Link to comment

Hi,

 

mal ne blöde frage..

bei

[Mobil High - 1500kBit]
Cmd=-threads {threads} {offset} -i "{infile}" -f mpegts -c:v libx264 -crf 21 -maxrate 1250k -bufsize 900k {framerate} -map 0:0 -map 0:1 -deinterlace -vf "scale={scalex}:{scaley}" -preset veryfast -tune film -vprofile main -level 3.1 -c:a libvo_aacenc -b:a 128k -ar 48000 -ac 2 -af volume=2.000000 -y "{outfile}"
maxWidth_IPhone=1136
maxHeight_IPhone=640
maxWidth_IPad=1280
maxHeight_IPad=720

 

soll es eine Bitrate von 1500 haben, aber wo wird dieser wert in dem Preset definiert ? ich sehe da nur was von maxrate 1250k ? oder ist das was anderes ?

Link to comment

statt einer fixen Bitrate, wie es Standardmäßig eingetragen ist (Preset [Medium 1280 kbit]: -b:v 930k -bt 1020k) -b:v steht für Bitrate Video ist fest auf 930kbit eingestellt. -bt steht für Bitratetoleranz. Beduetet, primär soll der Videoinhalt mit einer fixen Bitrate von 930kBit codiert werden. Bei Bedarf darf zugunsten der Qualität die Bitrate bis auf 1020kbit angehoben werden. Damit dass alles nicht überhand nimmt, wird (soviel ich weiß) mit der Bufsize (also einem Puffer) versucht, den durchschnittlichen Bitstrom auf 930kBit einzuhalten.

Schaut man jetzt z.B. die Tagesschau und man hat einen festen Hintergrund und die einzige Bewegung sind quasi die Lippen des Sprechers, so würde ffmpeg hier einen unnötig niedrigen Quantizer wählen. Man verschwendet quasi Bandbreite, da auch jetzt unnötige 930kBit übertragen werden.

 

Daher verwende ich -crf (Constant Rate Factor). Dieser stellt sicher, dass der Inhalt immer in gleicher visueller Qualität übertragen wird (Ein Wert von 18 bedeutet visuell Verlustfrei! Ein Wert höher 3 (21) reduziert den Datenstrom auf die Hälfte, kleiner 3 (15) verdoppelt den Datenstrom). Beim Nachrichtensprecher würde der Datenstrom auf vierlleicht 200kBit reduziert werden, da sich die Inhalte von Bild zu Bild nur minimal verändern. In einer Actionszene hingegen würde der Datenstrom entsprechend deutlich höher werden. Um das zu verhindern begrenze ich dies mit der Funktion "maxrate"

Bei Actionszenen hat man auch tatsächlich Artefakte, bei Nachrichten spart man aber deutlich Bandbreite ohne visuelle Einbußen und normales TV-Sendungen wie z.B. Big Bang Theory werden in den meiseten Szenen visuell einwandfrei übertragen ;)

Link to comment

Sorry, hab nochmal nachgelesen:

Increasing the CRF value +6 is roughly half the bitrate while -6 is roughly twice the bitrate. General usage is to choose the highest CRF value that still provides an acceptable quality. If the output looks good, then try a higher value and if it looks bad then choose a lower value.

Zitat (06.03.2013): http://ffmpeg.org/trac/ffmpeg/wiki/x264EncodingGuide

 

Ein Wert erhöht um den Wert 6 (25) reduziert den Datenstrom auf die Hälfte,verringert um 6 (12) verdoppelt den Datenstrom - so ist's richtig

Link to comment

Das ffmpeg abschmiert scheint behoben zu sein. Neuerdings tritt allerdings ein neuer Fehler auf. Der Dienst vom Recording Service friert ein. Erst hatte ich einen Zufall geglaubt, da kaum reproduzierbar. Heute ist dies zum dritten mal passiert. Man schaut Live-TV auf dem iPhone/iPad und irgendwann friert das Bild ein. Ein Blick in die svcdebug.log zeigt, dass nichts mehr passiert.

.
.
.
13.03.13 08:05:57.186 FFMPEG  frame= 3545 fps= 26 q=29.0 size=  8517kB time=00:02:20.59 bitrate= 496.2kbits/s dup=39 drop=0
13.03.13 08:05:57.705 FFMPEG  frame= 3559 fps= 26 q=29.0 size=  8547kB time=00:02:21.10 bitrate= 496.2kbits/s dup=39 drop=0
13.03.13 08:05:58.200 FFMPEG  frame= 3571 fps= 26 q=29.0 size=  8564kB time=00:02:21.59 bitrate= 495.5kbits/s dup=39 drop=0
13.03.13 08:05:58.542 TPipeServerReadThread Split            5055
13.03.13 08:05:58.709 FFMPEG  frame= 3585 fps= 26 q=29.0 size=  8615kB time=00:02:22.19 bitrate= 496.3kbits/s dup=39 drop=0
13.03.13 08:05:59.278 FFMPEG  frame= 3599 fps= 26 q=29.0 size=  8641kB time=00:02:22.70 bitrate= 496.0kbits/s dup=39 drop=0
13.03.13 08:05:59.756 FFMPEG  frame= 3609 fps= 26 q=29.0 size=  8659kB time=00:02:23.15 bitrate= 495.5kbits/s dup=39 drop=0
13.03.13 08:06:00.293 FFMPEG  frame= 3624 fps= 26 q=29.0 size=  8687kB time=00:02:23.79 bitrate= 494.9kbits/s dup=39 drop=0

 

zack, das war's. Kein weiterer Eintrag.

 

Die nächste Auffälligkeit beim beenden des Streams, also der klick auf den roten Button "Stop Streamserver". Es passiert nichts. Der Recordings Service reagiert nicht. Auch ein erneueter Aufruf der Internetseite bringt nichts, da der Recordings Service nicht antwortet.

Auf dem Server ein Blick in den Info-Bereich der Taskleiste. Der Recordings Service wird in gelb dargestellt und "scheint" zu laufen. Ein klick mit der rechten Maustatste um den Recordings Service zu stoppen. Das funktioniert auch noch. Die Farbe wechselt von gelb auf grau. Das Starten des Recording Servioce hingegen funktioniert dann nicht mehr! Der nächste Blick in den Dienstmanager. Der DVBViewer Recording Service wird mit Status "wird beendet" dargestellt. Ein starten, beenden, anhalten, fortsetzen. kann nicht angeklickt werden, da alles ausgegraut ist. Was ist das? Hat jemand noch das Problem?

Als Anhang die support.zip, allerdings meiner Meinung nach ohne Auffälligkeit

 

Abbhilfe schafft akktuel nur der Neustart des Servers. Zumindist ist mir keine andere Lösung bekannt!

 

Die support.zip ließ sich aufgrund der Größe (1.230kb) nicht hochladen!!

Edited by epsy
Link to comment

Hallo epsy

Ich habe das von Dir beschriebene Problem des Einfrierens des RS-Dienstes jüngst auch zwei drei mal genauso wie beschrieben gehabt. Dachte bisher "sowas kann ja - warum auch immer - zufällig mal passieren". Nach Deinem Beitrag bin ich jetzt doch skeptisch, kann aber außer meiner support.zip momentan leider nichts weiter beitragen.

Hilfslösung bis dato die gleiche: Server-Neustart.

Zumindest ist das vorherige Problem der Stream-Abbrüche, soweit der aktuelle Recording-Service 1.24 läuft, bei mir auch nicht mehr aufgetreten.

Link to comment

Moin Gisbert,

habe mir mal Deine support.zip angeschaut. Die support.zip stammt leider nicht direkt nach einem Absturz des Recordings Service. (oder irre ich mich?)

Dennoch ein kleiner Hinweis: Überarbeite mal Deine iphoneprefs.ini und entferne mal Testweise den Eintrag "-async 1". Du scheinst auch das Problem zu haben, dass sobald eine Serie/Film von einem Werbeblock unterbrochen wird, dass der Stream zusmammenbricht. Dann wechselt der Audiostream in ein anderes Format:

09.03.13 23:33:30.506 FFMPEG               Input stream #0:1 frame changed from rate:48000 fmt:fltp ch:2 chl:stereo to rate:48000 fmt:fltp ch:6 chl:5.1(side)

Danach kommt es zu gehäuften Fehlewrmeldung: invalid, clipping...

 

Abhilfe schafft das Entfernen des besagten Eintrags in der iphoneprefs.ini

 

Eine Asynchronität hatte ich dadurch SEHR selten! Den dadurch verursachten Streamabbruch konnte ich aber dauerhaft abstellen!

Link to comment

Du irrst nicht, die support.zip habe ich gestern vor meinem Beitrag erzeugt. Als ich das Einfrieren des RS hatte habe ich überhaupt nicht dran gedacht eine zu ziehen. Wenns wieder auftreten sollte, werde ich eine unmittelbar erzeugen.

Faszinierend ist für mich als IT-Laie, dass Du aus der svcdebug.log genau das raus liest, was ich als Problem gar nicht beschrieben, aber tatsächlich so habe - Werbeblock beginnt-->Stream bricht ab - Meine bisherige Lösung: Stop Streamserver --> Starte Stream (war nur suboptimal. Weil nervig? Ach wo, weil Werbung verpasst! grins)

Ich habe Deinem Abhilfetip gemäß gerade mal die iphoneprefs.ini bearbeitet und warte nun sehnsüchtig auf die nächste Werbeunterbrechung ;-)

Mal sehen ob es hilft.

Ergebnis: Stream läuft durch.

Danke epsy

Link to comment

Die neue Version der Elgato SAT>IP App läuft hier übrigens auch ganz passabel. Mittlerweile bin ich auch "jailbroken" auf iOS 6.1.2.

 

Mit der aktuell öffentlichen RS Version gibt es aber noch ein kleines Problem in Zusammenhang mit der Elgato App. Beim ersten Schalten auf einen Kanal kommt immer der Hinweise, dass das Gerät bereits in Verwendung wäre. Wenn man dann umschaltet, funktioniert es allerdings. In der nächsten Version wird das gefixt sein.

Link to comment

Nutze gelegentlich auch das Elgato-App, emfinde es aber als Bandbreitenverschwendung (Bild- und Tonaussetzer wenn man nicht optimalen WLAN-Empfang hat). Ausserdem funktioniert HD nicht und es läuft nur im heimischen Netzwerk! Genial allerdings, dass man zappen kann - Umschaltzeiten wie beim Fernseher!!

 

Zurück zum Problem, das der Recordings Service beim Streamen abschmiert:

Ein Neustart muss nicht sein habe ich festgestellt. Einfach im Taskmager unter Prozesse den DVBVservice.exe (mit der rechten Maustaste) "Prozess beenden" auswählen. Danach manuell die Datei "svcoptions.exe" starten. Ist im DVBViewer-Hauptverzeichnis! Ist übrigens gestern wieder abgeschmiert!
Nicht das jeder denkt ich schau den ganzen TV, aber ich habe hier ein altes iPhone 3GS liegen. Hab da ein neuen Akku eingebaut und traniere den soeben. Dadurch das WLAN, der Prozessor und der Bildschirm genutzt wird, kann man die Laufzeitsteigerung gut messen! Aufladen, Entladen, Aufladen, Entladen,... etc. Dadurch nutze ich den DVBViewer aktuell häufiger als sonst ;)

 

Link to comment

Nachdem sich bei mir der RS heute auch wieder aufgehangen hat, hier die aktuelle support.zip.

Situation: TV-livestream auf iPad3 und eine Aufnahme auf iPad1 angesehen.

Aufnahmestream blieb einfach stehen und kurz danach auch Livestream.

RS lies sich wie gehabt nicht beenden, auch nicht der Dienst im Taskmanager. Der Prozess DVBVService.exe konnte im Taskmanager beendet werden. RS konnte zwar wieder über Kontextmenü des Taskleistenicons gestartet werden, aber weder DVBViewer auf PC-Client, noch Webinterface oder iPad-App konnten zugreifen. Auf PC kam im DVBViewer die Meldung "Für diesen Sender ist kein DVB-Gerät verfügbar.". Am Ende habe ich Windows neu gestartet und alles war wieder o.K.

Ich hatte davor auch mal einige Einstellungsvarianten probiert. Bei HD-Sender kommt es immer mal zu kurzen Hängern, kriegt sich aber meist wieder ein. SD läuft auch mit höchster Bitrate durch.

 

support.zip

Link to comment

Die neue Version der Elgato SAT>IP App läuft hier übrigens auch ganz passabel. Mittlerweile bin ich auch "jailbroken" auf iOS 6.1.2.

 

Mit der aktuell öffentlichen RS Version gibt es aber noch ein kleines Problem in Zusammenhang mit der Elgato App. Beim ersten Schalten auf einen Kanal kommt immer der Hinweise, dass das Gerät bereits in Verwendung wäre. Wenn man dann umschaltet, funktioniert es allerdings. In der nächsten Version wird das gefixt sein.

 

Welche Version hat denn die Elgato Sat>IP? Ich habe die 1.0, aber im Play Store gibt es nicht aktuelleres.

Link to comment

elche Version hat denn die Elgato Sat>IP? Ich habe die 1.0, aber im Play Store gibt es nicht aktuelleres.

 

Die iOS App hat die Version 1.1.4 (131).

Link to comment

Wenn mir jmd hilft ffmpeg für ARM zu kompilieren und die c header files schreibt, bau ich das in die Android App auch noch ein ;-)

 

Aber das übersteigt mein Freizeit Zeit budget leider um einiges, da ich mich nicht auch noch mit c beschäftigen möchte...

 

Dann wärs allerdings aber auch eher DVBViewer für Android als nur ne kleine Spielerei ;-)

Link to comment

Wenn mir jmd hilft ffmpeg für ARM zu kompilieren und die c header files schreibt, bau ich das in die Android App auch noch ein ;-)

 

Aber das übersteigt mein Freizeit Zeit budget leider um einiges, da ich mich nicht auch noch mit c beschäftigen möchte...

 

Dann wärs allerdings aber auch eher DVBViewer für Android als nur ne kleine Spielerei ;-)

Hilft das ?

 

http://ffmpeg.org/trac/ffmpeg/wiki/How%20to%20compile%20FFmpeg%20for%20Raspberry%20Pi%20%28Raspbian%29

Link to comment
×
×
  • Create New...