[haikuginger]

Hi all,

First off, I want to thank you for this wonderful, wonderful add-in. WMC is the gold standard for ease of use in configuring a set of TV tuners, so it makes me incredibly happy to be able to use it alongside XBMC, both on the WMC host machine running Windows 7 x64, and my living-room HTPC running OpenELEC.

The issue I had today isn't a huge one; I'm not even sure if it's not intended behavior, but I thought I'd bring it up.

Basically, I set up a recording of the Olympics and switched to it when it was about an hour and a half in. In particular, my wife and I wanted to watch the ice dancing competition, which started about an hour into the recording.

After opening the live recording, I expected the TS to load up to the current position, but instead, the "end" of the stream stayed at between 7 and 8 seconds ahead of the current playback position. If I paused the file, the mux also appeared to pause. If I fast-forwarded, then the TS would mux ahead of my fast-forward (although I'm not sure if I was actually able to fast-forward at full speed). If I rewound, the TS would stay at its present point of muxing until playback reached the same point again; then, it would again start muxing about 7-8 seconds ahead of playback.

It's a relatively minor complaint, because even this is still better than a lot of other options. But it bugged me, because instead of just being able to enter in a time to jump to numerically, I had to have XBMC set to fast forward at 32x for several minutes.

I was able to reproduce this on both my OpenELEC box with the nbox skin, and on the Windows 7 box with both the nbox skin and Confluence. Both are running Frodo; one is 12.2 and the other is 12.3.

I made the attached log file with server version 1.0.0.23, but once I realized there was a newer version, I updated to 1.0.0.24 which had the same behavior. Both plugins are 0.1.93 from the website; Windows is the universal version, and the OpenELEC box is using the Linux x64 version.

http://pastebin.com/V7TWgMR6

Basically, my frustration is that the mux progress of the TS file appears to be linked to the point of playback inside the TS, rather than the current length of the active recording. That may have been intended behavior; I'm not sure. But, if it is, I'd like to see a preference to have the mux cover the entire file, rather than the current playback point.

[scarecrow420]

Hi haikuginger,

Yes we are aware of this but haven't figured anything out as yet. It's a bit strange because the remux job is in no way linked to what XBMC is viewing/doing. ServerWMC actually has little idea what XBMC is doing inside the file, in terms of reading, seeking, pausing, fast forwarding etc. We dont know if playback is paused (which would actually be helpful if we did, for some other stuff we wanted to do) so there really isnt any way that the remux job wouldnt be going through the WTV file as fast as it can. We havent gotten to the bottom of it yet. It would be an interesting test, to open the TS file of the in progress recording in media player classic or another application, to verify just how much of the video is present in the TS file. That would help confirm whether it's the TS file/remuxer itself that is somehow limiting what is there or producing it very slowly, or whether it is some weird thing with XBMC reading the file.

The last time this came up, we decided to add an option to stop the remux of in progress recordings. If you enable this option, we will pass the WTV file straight to XBMC rather than a remuxed TS file. This isn't without it's own issues though, because the whole reason for remuxing is that XBMC will only play the WTV file up to the filesize that it was when playback began (so in your case it would have stopped at the 1hr:30m mark) but it does however let you skip to any point in the file (up to that max size). So in your case this behaviour would probably have been ok - you can skip striaght to your hour mark, watch the ice dancing (but after 30 minutes it would stop). At that point though (and once you are on Gotham build where we can support resume functionality) you would just have to hit play on the recording again, and it would ask "do you want to resume from 1hr:30m" so it would be a minor inconvenience. unfortunately on Frodo we cant support the resume feature without some ugly tradeoffs so it's gotham only at this stage.

So basically you have the choice between

- ability to skip to any point in the recording with the tradeoff that playback stops at the current max size rather than seeing the growing file (but gotham resume function minimises that inconvenience)
- remuxed TS that lets you watch out the in progress recording right to the end, but seems to have issues with getting more than a little ways ahead of the current viewing point

If you want the first one, set the option "remux in progress recordings" to false.

hopefully this post will remind us that we need to look at the remuxer/TS/XBMC side of things with respect to in progress recordings

[haikuginger]

It would be an interesting test, to open the TS file of the in progress recording in media player classic or another application, to verify just how much of the video is present in the TS file.

That's certainly something I'll be happy to try and give you results on. Do you need more configuration information to see if you can find a common cause for this issue, or is it a universal problem?

[scarecrow420]

This isn't the first time it's come up so Im thinking it's probably affecting everyone. Definitely let us know what state the TS seems to be in, extra data/testers are always appreciated

[haikuginger]

Okay, so as far as I can tell, the .ts file is being muxed at full speed, but XBMC isn't loading it in its entirety for some reason. It seems like there's possibly some sort of network conservation measure in effect that's only loading from the .ts just in time for playback. I'll do some testing later to see if it happens with all .ts files under XBMC, and if not, what the requirements seem to be.

[haikuginger]

All right, this issue doesn't happen on just any .ts file. In fact, I tried copying the TS file being made by ServerWMC to another folder mid-stream. After copying it out and importing it into XBMC, it played perfectly; it showed the full amount of time available in that file and I was able to jump around inside it.

There's something going on with XBMC not wanting to open the full file if it's still being added to; I'm not sure what the cause is, though.

[Dilligaf]

If you're using Gotham you could try changing cache settings http://wiki.xbmc.org/index.php?title=HOW..._the_cache specifically <cachemembuffersize>0</cachemembuffersize> which will cache to the hard drive which should give you a bigger ff/rw with Frodo I don't think these settings will work with local network streaming.

[krustyreturns]

For 'active' wtv files (ones that are being recorded too), xbmc doesn't seem to want to re access the file length, because of this it makes it difficult to fast foward (I usually have more luck with skip ahead), It actually works better in live tv streams, where I think xbmc knows it has to pay more attention to the file length.

It would be nice of an xbmc guru could help us understand what is going on with this issue. Also I wonder what would happen if we forced a feed a fake large file length into xbmc?

[Dilligaf]

For 'active' wtv files (ones that are being recorded too), xbmc doesn't seem to want to re access the file length, because of this it makes it difficult to fast foward (I usually have more luck with skip ahead), It actually works better in live tv streams, where I think xbmc knows it has to pay more attention to the file length.

It would be nice of an xbmc guru could help us understand what is going on with this issue. Also I wonder what would happen if we forced a feed a fake large file length into xbmc?

If I start a channel on a second client that is already playing on another client I seem to lose the ability to skip forward/back when I skip it skips between the current live position and the beginning point where the channel was originally started on the first client

[haikuginger]

If you're using Gotham you could try changing cache settings http://wiki.xbmc.org/index.php?title=HOW..._the_cache specifically <cachemembuffersize>0</cachemembuffersize> which will cache to the hard drive which should give you a bigger ff/rw with Frodo I don't think these settings will work with local network streaming.

I'm actually thinking that increasing <readbufferfactor> might be the way to go on Gotham (but I'm stuck on Frodo until OpenELEC updates). But, the really odd issue isn't that not much gets buffered; it's that XBMC doesn't know where the current end of the file is. If I'm playing a recording that's going on right now, it constantly shows me as being 7-8 seconds from the end of the file, although it updates before I reach the "end".

[krustyreturns]

I just double checked and even when playing an active recording, xbmc is constantly querying for the ts file size - so at some level it knows the file size. I think the problem is it only decides the play length once when the view starts, and never re-evaluates.

One idea we have kicked around is during 'prime time' starting a remux thread for every active recording so all the ts files are at the limit when viewing starts. Then of course cleaning them up when the recording finishes.

[haikuginger]

I just double checked and even when playing an active recording, xbmc is constantly querying for the ts file size - so at some level it knows the file size. I think the problem is it only decides the play length once when the view starts, and never re-evaluates.

Has a bug report for that behavior been filed with xbmc? A fix for that would obviously be the ideal solution.

[krustyreturns]

Has a bug report for that behavior been filed with xbmc? A fix for that would obviously be the ideal solution.

Yes, that would be ideal - and a bug report has not been submitted for it.

[haikuginger]

Yes, that would be ideal - and a bug report has not been submitted for it.

All right. Would someone running Gotham like to reproduce and log that issue, then file the report? I would, but I'm only on Frodo, and since Frodo's at the end of its support, it'll probably mean more coming from someone running a prerelease build of Gotham, especially if it's from the developer of a major PVR plugin.

[scarecrow420]

Another strange thing I just noticed is that I paused live TV (this was after a stream had been running an hour or so, though im not sure if it matters) and eventhough the progress indicator (in the top right of the screen) said pause, the current position/time was still incrementing every second