Unfortunately the latest version still doesn't work for me. It thinks (or the "bug" could be with Serviio) I have an active connection with my Sony BluRay 6 hours after I switched off the BluRay player. IOW it never lets the computer sleep.

Was this straight after coming out of hibernation - did WinHelper detect that the connection was closed some time later?

Sometimes the TCP connection between Serviio and your device is still active even after device has shut down (the TCP connection is used by WinHelper to "detect streaming"). This occurs when the device doesn't close the streaming session that it initiated properly (eg. if you turn the device off rather than stopping the movie and then powering off). Windows should detect these "half open" sessions after a while and close them - WinHelper will then pick up that the session is closed and respond accordingly. Sometimes however Windows never cleans these sessions and we have a problem.

If it happens again can you please also capture a full list of network connections (right click on the WinHelper icon in your system tray and select Network Connections from the context menu) so that I can see the state of the active connections at that time. Pressing Check Now will also force WinHelper to check the connections status. Although not ideal you can also remove your Bluray from the WinHelper sleep management system in WinHelper by double clicking on the device in the WinHelper Sleep tab.

As far as Serviio detecting the device is not active, unfortunately the Serviio status check may not be reliable enough: see viewtopic.php?f=17&t=12136&start=40#p87062 and my response. Since then I have acquired few more devices and it is a mixed bag - one, a Yamaha RX-V500D shows as active in Serviio even when powered down (standby mode). Notwithstanding, I am looking at adding a second level of checking in the next release as it may help some users.

It did the same thing last time I tried it too. Even after I turn off the BluRay player, WinHelper is still picking up the connction and thinking it's there (maybe it doesn't terminate cleanly? Why is there no timeout?).

In this case I turned it off, and then a few hours later I noticed the computer hadn't gone to sleep yet. I manually put it to hibernate. Then next day I switched it back on, and WinHelper was still detecting an active connection to the BluRay (even when Serviio, as in the picture, can see it's off the network).

Maybe you could add a second option based on network activity over said network connection.

WinHelper is only detecting the connection status as Windows reports it. As per my last post I'd appreciate if you could post the complete list of active connections at the time either by right clicking on the WinHelper icon or (better) running the DOS command "netstat -a -n" so that I can confirm that WinHelper is detecting it as Windows is seeing it (I want to rule out any bug in that process first).

If I remux a MKV file with multiple audio and caption tracks, will they remain as a selectable option in my player, or do they get hard coded into the new container? Does the MP4 container even support this? Currently, most of my DVD rips have captions, and my Blu-Ray rips usually have the HD audio as well as the lossy track. With my Sonly BD players, I can choose between them (of course, the BD captions aren't rendered because Serviio doesn't support that type yet). The Roku players can't select captions because they are all being transcoded into mpeg-ts. I was thinking that the Roku might be able to display the text since it will play an MP4 without transcoding.

WinHelper uses ffmpeg to do the remuxing - the command that is issued is: ffmpeg -i filename.mkv -c copy -map 0 filename.mp4. This copies all streams from the original container to the new container.

To see whether a stream is supported in the MP4 container have a read of http://en.wikipedia.org/wiki/Comparison ... er_formats and http://www.mp4ra.org/codecs.html. MP4's have less support for subtitle and audio formats than MKV's. To be honest I'm not sure what happens if a stream that is not supported in the MP4 is copied into it - whether it is copied anyway or whether the ffmpeg remux process rejects it or fails (I haven't seen any evidence of this and I use this quite extensively - having said that my collection doesn't include many subtitles and most audio is pretty standard - AAC or AC3).

I suspect the stream is copied anyway. This doesn't mean that it will be playable on your devices - that is up to the device. Some don't support all "standard" combinations, and others support a variety of "non-standard" combinations. Only advice I can give is to try it, use MediaInfo to confirm the stream is copied, and then play it on the target device.

WinHelper uses ffmpeg to do the remuxing - the command that is issued is: ffmpeg -i filename.mkv -c copy -map 0 filename.mp4. This copies all streams from the original container to the new container.

To see whether a stream is supported in the MP4 container have a read of http://en.wikipedia.org/wiki/Comparison ... er_formats and http://www.mp4ra.org/codecs.html. MP4's have less support for subtitle and audio formats than MKV's. To be honest I'm not sure what happens if a stream that is not supported in the MP4 is copied into it - whether it is copied anyway or whether the ffmpeg remux process rejects it or fails (I haven't seen any evidence of this and I use this quite extensively - having said that my collection doesn't include many subtitles and most audio is pretty standard - AAC or AC3).

I suspect the stream is copied anyway. This doesn't mean that it will be playable on your devices - that is up to the device. Some don't support all "standard" combinations, and others support a variety of "non-standard" combinations. Only advice I can give is to try it, use MediaInfo to confirm the stream is copied, and then play it on the target device.

Thanks my friend. I'll try it on a couple of videos and see what the Roku does with it.

OK, I tried it using your tool, as well as the command line you listed. Both times it shows a successful conversion. However, Serviio won't recognize it as a valid video and Windows Media Player won't play it. No errors, just won't load and play. VLC will play it with no problem. Serviio log shows it being added to the library.

A bit off-topic for WinHelper, but you may want to try to determine which stream is causing the issue by doing a number of tests:

Copy only the first video and audio streams leaving any menu and subs behind: ffmpeg -i filename.mkv -c:v copy -c:a copy filename.mp4. I suspect this may work as I think the issue relates to VobSubs which is not a text based subtitles format.

If the above doesn't work, copy only the first video stream and transcode the first audio stream: ffmpeg -i filename.mkv -c:v copy -c:a aac filename1.mp4Hopefully one of the above 2 works as it may give you an easy fix.

and if still not working, transcode both the first video stream and the first audio stream: ffmpeg -i filename.mkv -c:v libx264 -preset ultrafast -qp 0 -c:a aac filename2.mp4 although if you get to this point you may as well re-encode everything from scratch!

Once you know what stream is causing you grief you can work out a strategy to move forward (ps. I may not have all of the above commands right - google for assistance - and they are certainly not done to produce the best quality, only to try and identify the stream that is causing the issue). Let me know which if any of the above produce a playable file.

I think we are on topic for WinHelper, since I had the issue using it as well as command line

Option 1: no change. Serviio did not recognize it, and would not play in Windows Media PlayerOption 2: no changeOption 3: no video, but the audio plays (had to add "-strict -2" for aac to work)Option 4: audio and video played through Serviio, still won't play in WMP. However, the file was transcoded instead of playing native. Also, the file became 6 times larger (3.3G to 20g)

Edit: I see why it is being transcoded. The High 4:4:4 is tripping it. Have to drop the level to 4.2 or less. Don't know how to do that.

The problem with recoding everything is that my ripping tool is MakeMKV, so I don't have any output option besides MKV. I haven't found anything else that will rip a disc and leave the multiple audio and caption tracks in place. Everything will just burn the captions in hard, and only allows one audio track. I'm even willing to buy something that would do that, but maybe I'm using the wrong search terms.

I think we are on topic for WinHelper, since I had the issue using it as well as command line

Well not really The Remux command in WinHelper is purely that - it remuxes all streams. There is no attempt to adhere to standard combinations or fix broken streams.There is also no guarantee that the resultant file is playable - see: viewtopic.php?f=17&t=12136&p=80505#p80505. To do otherwise would require that WinHelper become a full video re-encoder and there are enough of them around already (XMedia Recode is my re-encoder of choice).

Anyways, I think your MKV's have a number different issues that are causing you some grief.

Firstly your subtitles: VobSub is an image based subtitle format. It is not supported by many devices, and even where supported seems limited to MKV files (apparently Nero can transcode? them into an MP4 file, but I suspect it is a simple remux which ffmpeg does anyway. Maybe give it a try). Being image based ffmpeg (and hence Serviio) has no way at this stage to transcode it or burn them in (which is why you loose them on transcoding). There are tools to do so (google for VobSub to srt, SubExtractor, or read: http://forum.videohelp.com/threads/2097 ... -subtitles), but they involve Optical Character Recognition and a bit of time. Notwithstanding, it may be a partial answer for you - converting to text based subs and then remuxing that back into your file will make it readable by more devices (you should also be able to keep you VobSub stream as well - MKV and MP4 containers can support multiple sub streams, but remember VobSub isn't standard in MP4's so it may pay to make the VobSub the second sub stream). Doing this should allow Serviio to transcode the file and burn in subs for your Roku box.

Secondly, your video stream. There seems to be something in the way it is encoded that is not liked by the Roku (and Media Player) when you remux it into MP4 (does ffmpeg display any warnings or errors when remuxing). AFAIK both MKV and MP4 should be able to support mpeg2 streams natively, but there are so many variables: it could be the overall bit rate, the variable frame rate, the format settings, etc, etc. Unfortunately, it is probably a matter of playing - a simple thing to do is to look at the ffmpeg command Serviio invokes when transcoding the file for the Roku (which we know works - turn on detailed logging to see this command) and then manually do that, changing from an mpegts container to an mp4 container type.

Good luck. It can be painful finding the right format across multiple devices.

Added an option (Settings Tab) to test the status of the device as reported by the Serviio server when testing for TCP connections. Will help some users recover from half open TCP connections that result when devices are ungracefully shut down. This option is enabled by default;

minor bug where settings were not being saved in registry on first use

Sorry - I haven't documented that very well. The option is on the Settings tab as a checkbox labelled "Sleep Management: Ignore connections to renderers marked as Inactive by Serviio". It is on by default.

DenyAll wrote:Sorry - I haven't documented that very well. The option is on the Settings tab as a checkbox labelled "Sleep Management: Ignore connections to renderers marked as Inactive by Serviio". It is on by default.

WinHelper looks for established TCP sessions on ports 8895 and 23424 between Serviio and your renderers. When it finds these sessions it infers that Serviio is streaming and stops your PC going to sleep. When the TCP session closes (ceases to exist), WinHelper puts your PC back to normal sleep mode (ie. allows the operating system to once again control when your PC goes to sleep).

Problem is, sometimes a TCP session is held up even after the renderer has stopped streaming - generally this happens if the renderer was turned off ungracefully (ie. before stopping the movie, closing the Media Server screen on your TV, etc). These 'orphan' TCP sessions are generally cleaned up by Windows... but some users have reported that in their system the session never closes (or closes some hours later). In these cases your PC never goes to sleep - an active session is always detected and Winhelper always stops your PC going to sleep. Its not common amongst the user group, but if you are unfortunate and it does affect your system, it makes WinHelper's sleep management less than useful .

This new checkbox provides an attempt to deal with this issue. It provides a second level of checking - if a TCP session is found and this checkbox is active, WinHelper will also check the Serviio Server to see what it believes the status of the renderer is:

If Serviio has tagged the render as "Inactive" then WinHelper will allow your PC to go to sleep, despite the active TCP session still existing - ie. Serviio has detected that the renderer is turned off, so ignore the fact that a session still exists.

If the Serviio server has the renderer marked as "Active" or it cannot determine the status of the renderer (status = "Unknown"), this second level check has no effect - ie. the existence of the TCP session is the sole determinant of the sleep mode.

This checkbox only adds value if you were having issues with your PC never going to sleep due to 'orphaned' TCP sessions AND Serviio is accurately able to detect when your renderer is Active/Inactive (for most of my renderers for example, Serviio cannot determine the status and simply marks them as "Unknown").