I noticed this every time when the disks went to sleep, the playback terminates back to the previous page whichever it was before starting to play. Playing any media even with Direct Play will result in termination during playback. Hi again the recent version 10.8.9, it seems to be getting worst. Maybe you can stall the request with a reverse proxy. I don't remember if these requests are visible in the Network tab. You can try to catch them with Wireshark. main.m3u8 - list of TS (or fMP4) segments.master.m3u8 - contains a link to the actual stream ( main.m3u8).When Remuxing, DirectStreaming or Transcoding, the TV requests: Ideally, we should probably add a client-side timeout as well.ĭo you have any idea how to simulate the server not responding to a playback behavior without actually interrupting the connections? ![]() There was a bug - jellyfin/jellyfin#6558. This can probably be reproduced by placing a breakpoint when debugging the server, but you need to setup some C# IDE (VS Code) + install. Probably the disk wasn't in deep sleep long enough? Maybe we can manually make the player to retry several times until an error occurs or playback starts. If there is no error in the browser console, we may need a custom timeout. ![]() ![]() Looks like the TV doesn't retry and just waits for a response. However at this point, the GUI is no longer responding so I'm stuck at the circle animation with the media's photoart background for several minutes and the only way is to force close the app by holding the remote's back button. I was thinking of replacing the ffmpeg with an infinite sleep loop (I did this previously using perl to intercept then regex replace the output parameters adding -noautorotate, this was when I had video rotating issues long ago with -hwaccel which seems to be solved on the recent JF ffmpeg) but that wasn't the case because the transcoding did actually occurred. I have never seen this, do you have any idea how to simulate the server not responding to a playback behavior without actually interrupting the connections? Probably then I can use it to debug what's going on. Then it retried different transcoding settings (2-3 times in total). Last time I tested Tizen app with the server not responding, it took 30sec to throw an error. But I'm very sure the issue happened almost every time I see my disks LEDs pulsing indicating it's on standby. I tried to simulate this by forcing my disks to go on standby with hdparm -y /dev/sd, ensuring it's really on standby, then click play but unfortunately I couldn't produce the same issue, probably the disk wasn't in deep sleep long enough? I'm not sure it's quite tough to test with external users randomly accessing the server. Yes the transcoding did kicked in, I could see the ffmpeg consuming resources and the transcoding log/tmp files exists. However at this point, the GUI is no longer responding so I'm stuck at the circle animation with the media's photoart background for several minutes and the only way is to force close the app by holding the remote's back button.ĭoes the server actually start transcoding? Maybe it just doesn't respond at all. I knew the disks had resumed when its LEDs starts blinking, also from checking with hdparm -C /dev/sd showing active/idle instead of standby. I waited about 10 secs +/- for all the 4 disks to resume while JF-Tizen is showing the circle animation after pressing play. I just hope there a way to increase this timeout to accommodate the sleeping disks + the time it requires to buffer the transcoding/remuxing. ![]() Of course when I open the app again, I can resume playback almost immediately as the disks are already awakened. When this happened, I can no longer interact with the UI, only way is to force close by holding the TV remotes' back button. The media is however stored on a RAID 10 mechanical 4x10TB 7200RPM 256MB cache disks which often I would want them to go on standby when not in use (reduce power usage and temperature).īut when I click play on the TV with transcoding or remuxing is required (direct play seems fine), it often ends up in an infinite loading circle when the disks are still asleep awaiting them all to each spin up then resume. I also have web assets and images cached on the RAM so everything is snappy. Here's the deal, JF server is running off an SSD on my NAS which is set to never sleeps on top of others like reverse proxy, Debian 10 OS stuffs etc. Is there any way to increase the media operations timeout, play/fwd/rwd etc? I'm asking because it seems only with JF-Tizen I have this issue, but not with the JF-Web.
0 Comments
Leave a Reply. |