[IanPH]

I was happily surprised to see wmc.pvr released for android a few days ago.
I had to change some configs both on my firewall and the ServerWMC config to make it work and ready to test it out on my Galaxy S4.
But just when I expected the video to start after I selected a channel, XBMC crashed and I was back in the launcher.

A half an hour later I logged in to my server and saw a lot of disk activity. Further investigation revealed ServerWMC never "noticed" XBMC stopped working on my phone and was happily "streaming" (or better said, never closed the channel on my tuner).

Could it be somehow be possible to communitate some sort of "alive" check every minute or so, between wmc.pvr and ServerWMC to make sure the channel will be closed as soon as XBMC somehow crashed. I mean, even my OpenELEC HTPC crashed once. I think this is a scenario that might actually happen quite often.

An other approach might be to periodically check it the "share" to the videofile created for streaming is still opened.

I noticed that in CMD-> compmgmt.msc under "Shared Folders"->"Open Files" I could see the file was open and as soon as I pulled the plug from my OpenELEC htpc the share was no longer in that list (Even though ServerWMC still indicated it as an active stream). I guess there must be a way to check this with some coding, and close the channel as soon as the share it no longer open.

[scarecrow420]

It's a bit odd, there is already a healthcheck sent from the client to the server periodically, and the server sets a client offline when it hasnt heard from it for a little while. This should then cause any streams that have no clients viewing them to be to shut down. I will do some testing/debugging tonight if krusty doesnt get to this first

[cmh32765]

I had noticed this issue too a few days back. Just thought it was something with my system. Had some networking issues with a new BIOS I installed.

Anyway, could there be an option/button to "kick" or stop a stream from where it shows that it is playing? Could be used to help this issue, as well as boot someone watching something that you don't want them to (i.e. child). Or, could just be used for some fun around the house. 8)

[scarecrow420]

Personally I would rather make the server reisllient and automatically stop streams that clients are no longer accessing (Like it should be doing already) rather than have GUI control to stop individual streams etc... But hey, anything is possible and if enough people want something that makes us more compelled to do it.

Restarting the ServerWMC application of course, will stop all streams (both orphaned ones and real ones) if you want a sledge hammer approach!

[IanPH]

Yeah that was what I eventually did, stop ServerWMC.

But indeed, it should do it by itself. Maybe (I'm not sure as I'm not really a developer myself) the approach to check the opened share on the Windows side might be a more reliable way to see if the stream is still in use?!

[krustyreturns]

@Ian, did you reconnect with the same client within a few minutes of the crash?

I agree with scarecrow that the server should be able to detect the stream's health on its own. But I also like the kick button idea.

[IanPH]

No I did not. I just left it for what it was and about 30 minutes later discovered ServerWMC still had the stream open.
I you want to, I can do specific tests for you.

[krustyreturns]

Thanks. Yeah, we may need you to try to reproduce. I can't do it right now though (and to be honest I can't recall how this portion of the code works). Maybe scarecrow will get to it sooner. Annoying, I thought this run-away stream thing was solved problem, maybe something we did recently broke it. You weren't doing an instant-record or anything right? Just viewing the stream?

[IanPH]

Indeed. Actually because XBMC on my Galaxy S4 crashed right at the point where it shows the time/buffer popup (in the upper right corner) just before it should normally start the playback, I actually didn't even see it stream. No recordings where running or scheduled at the time.

[scarecrow420]

Ive only had a brief look at the code, but it seems there could be an issue if the client crashes after it calls GetStreamSize() as the purge logic seems to only delete streams that are 2 minutes old that the client hasn't started reading. So it seems possible that if the client HAS started reading it, the stream doesnt get purged after 2 minutes. Ill try and do some actual debugging/fixing later

[krustyreturns]

I can reproduce Ian's problem. I am working on a fix now. The timing is actually good because mb3 has a related issue, so I can kill both bugs at the same time (hopefully).

[IanPH]

Due to personal matters I haven't been on the board for a few days. But I would like to thank you very much for looking in to this.

[krustyreturns]

No problem. The fix will be in the next release.