Login at Kodi Home

scarecrow420 · 2013-09-12, 15:09

If everyone can give their feedback on channel change times that would be useful. As has been mentioned in the thread we cant do anything about XBMC itself and the few seconds it takes to play the stream, ideally you need to grab the output from log (look at the Debug tab on the ServerWMC backend application)

Personally I have found some backend channel changes as quick as 1 or 2 seconds, but have also had some very long ones at 9 seconds. This is all from the log file and before you get the few seconds that XBMC also takes. I also had one case where the channel change didnt go through, the log file showed "ts file doesnt exist after timeout" type error. That channel later worked fine and I havent been able to reproduce it for now

For me, the majority of time on the channel changes is in the ScreamDescriptor parsing as per this log output:

2013/09/12 22:53:06.582 Remux::FindDescriptors> Scanning wtv for streams...
2013/09/12 22:53:07.417 Parse> Guid: 0 took 0.84 sec, it was attempted 417 times
2013/09/12 22:53:07.417 Parse> Guid: 1 took 0.00 sec, it was attempted 0 times
2013/09/12 22:53:12.417 Parse> a/v streamdescriptors found in: 5.00 sec
2013/09/12 22:53:12.417 Parse> total descriptor parse time: 5.84 sec

On a related note, I have got the pvr.wmc addon working with XBMC Gotham and submitted the code for that to Krusty, so he might be able to post up a addon build for those wanting to run Gotham nightly builds etc. Unfortunately the channel change on the XBMC side doesnt seem to be improved, whereas from what I was digging through I was expecting that some FFMpeg changes from FernetMenta and Margro etc which were included in Gotham, were meant to speed things up. This is just from a seat of the pants opinion though, I havent got any actual timings on teh XBMC side nor have I gone back to Frodo and tried things again there etc

hoopsdavis · (This post was last modified: 2013-09-12, 15:18 by hoopsdavis.)

Guys can you post your channel change speeds so we can get an idea if everyone is getting around the same average speeds.

(2013-09-12, 15:09)scarecrow420 Wrote: If everyone can give their feedback on channel change times that would be useful. As has been mentioned in the thread we cant do anything about XBMC itself and the few seconds it takes to play the stream, ideally you need to grab the output from log (look at the Debug tab on the ServerWMC backend application)

Personally I have found some backend channel changes as quick as 1 or 2 seconds, but have also had some very long ones at 9 seconds. This is all from the log file and before you get the few seconds that XBMC also takes. I also had one case where the channel change didnt go through, the log file showed "ts file doesnt exist after timeout" type error. That channel later worked fine and I havent been able to reproduce it for now

For me, the majority of time on the channel changes is in the ScreamDescriptor parsing as per this log output:

2013/09/12 22:53:06.582 Remux::FindDescriptors> Scanning wtv for streams...
2013/09/12 22:53:07.417 Parse> Guid: 0 took 0.84 sec, it was attempted 417 times
2013/09/12 22:53:07.417 Parse> Guid: 1 took 0.00 sec, it was attempted 0 times
2013/09/12 22:53:12.417 Parse> a/v streamdescriptors found in: 5.00 sec
2013/09/12 22:53:12.417 Parse> total descriptor parse time: 5.84 sec

On a related note, I have got the pvr.wmc addon working with XBMC Gotham and submitted the code for that to Krusty, so he might be able to post up a addon build for those wanting to run Gotham nightly builds etc. Unfortunately the channel change on the XBMC side doesnt seem to be improved, whereas from what I was digging through I was expecting that some FFMpeg changes from FernetMenta and Margro etc which were included in Gotham, were meant to speed things up. This is just from a seat of the pants opinion though, I havent got any actual timings on teh XBMC side nor have I gone back to Frodo and tried things again there etc

Looks like we were both thinking the same thing. I'm getting an average of 4 seconds with QAM (going from one qam channel to another was even quicker) and 6.5 with Digital (set-top-box)

Scarecrow, one thing I wanted to mention, while testing I constantly ran into issues using the margo build, although the channel change times were quicker with margo the video was unstable, with constant jumps and millisecond pauses. I believe someone else experienced this also.

scarecrow420 · (This post was last modified: 2013-09-12, 15:37 by scarecrow420.)

(2013-09-12, 15:09)hoopsdavis Wrote: Guys can you post your channel change speeds so we can get an idea if everyone is getting around the same average speeds.

(2013-09-12, 15:09)scarecrow420 Wrote: If everyone can give their feedback on channel change times that would be useful. As has been mentioned in the thread we cant do anything about XBMC itself and the few seconds it takes to play the stream, ideally you need to grab the output from log (look at the Debug tab on the ServerWMC backend application)

Personally I have found some backend channel changes as quick as 1 or 2 seconds, but have also had some very long ones at 9 seconds. This is all from the log file and before you get the few seconds that XBMC also takes. I also had one case where the channel change didnt go through, the log file showed "ts file doesnt exist after timeout" type error. That channel later worked fine and I havent been able to reproduce it for now

For me, the majority of time on the channel changes is in the ScreamDescriptor parsing as per this log output:

2013/09/12 22:53:06.582 Remux::FindDescriptors> Scanning wtv for streams...
2013/09/12 22:53:07.417 Parse> Guid: 0 took 0.84 sec, it was attempted 417 times
2013/09/12 22:53:07.417 Parse> Guid: 1 took 0.00 sec, it was attempted 0 times
2013/09/12 22:53:12.417 Parse> a/v streamdescriptors found in: 5.00 sec
2013/09/12 22:53:12.417 Parse> total descriptor parse time: 5.84 sec

On a related note, I have got the pvr.wmc addon working with XBMC Gotham and submitted the code for that to Krusty, so he might be able to post up a addon build for those wanting to run Gotham nightly builds etc. Unfortunately the channel change on the XBMC side doesnt seem to be improved, whereas from what I was digging through I was expecting that some FFMpeg changes from FernetMenta and Margro etc which were included in Gotham, were meant to speed things up. This is just from a seat of the pants opinion though, I havent got any actual timings on teh XBMC side nor have I gone back to Frodo and tried things again there etc

Looks like we were both thinking the same thing. I'm getting an average of 4 seconds with QAM (going from one qam channel to another was even quicker) and 6.5 with Digital (set-top-box)

Scarecrow, one thing I wanted to mention, while testing I constantly ran into issues using the margo build, although the channel change times were quicker with margo the video was unstable, with constant jumps and millisecond pauses. I believe someone else experienced this also.

yes the margro build only included some basic hacks to tell XBMC not to wait as long for live TV streams but that could lead to it not identifying teh stream properly, or having refdresh rate changes come through afte the stream had already started displayiong etc

upstream changes were made in ffmpeg seemingly in a more "proper" way to handle this (something about identifying PMT changes in streams whatever they are!) and from what I thought I read, this was meant to be the proper fix to this issue rather than telling XBMC to give up after a smaller amount of time

Anyway, i dont have any video issues under Gotham (basic testing only) however I cant say the front end channel changing speed (streaming etc) seems to have any improvements either... The guys over in the media portal addon is where this stuff all started (Margro is MP dev, FernetMenta is XBMC/ffmpeg) so I will have some discussions over there with them maybe

These are the pull requests that ultimately went into XBMC Gotham. By this stage they arent referring to speeding up PVR channel changes however I got to these by following bread crumbs from the Margro "fix" to set the lower timeout threshold on stream identification for LiveTV... that ultimately led to "upstream FFMPEG changes" fixing this properly (supposedly)

https://github.com/xbmc/xbmc/pull/2701
https://github.com/xbmc/xbmc/pull/1757

The interesting thing is that there are these comments "pvr clients which use this demuxer need to send pat/pmt at least when there are changes." so perhaps we actually need to do something on our side now. I guess I need to school up on all this audio/video stream stuff etc. Or just leave it krusty and Ill work on more infrastructury type changes hehe Smile

hoopsdavis · 2013-09-12, 15:47

(2013-09-12, 15:33)scarecrow420 Wrote:
(2013-09-12, 15:09)hoopsdavis Wrote: Guys can you post your channel change speeds so we can get an idea if everyone is getting around the same average speeds.

(2013-09-12, 15:09)scarecrow420 Wrote: If everyone can give their feedback on channel change times that would be useful. As has been mentioned in the thread we cant do anything about XBMC itself and the few seconds it takes to play the stream, ideally you need to grab the output from log (look at the Debug tab on the ServerWMC backend application)

Personally I have found some backend channel changes as quick as 1 or 2 seconds, but have also had some very long ones at 9 seconds. This is all from the log file and before you get the few seconds that XBMC also takes. I also had one case where the channel change didnt go through, the log file showed "ts file doesnt exist after timeout" type error. That channel later worked fine and I havent been able to reproduce it for now

For me, the majority of time on the channel changes is in the ScreamDescriptor parsing as per this log output:

2013/09/12 22:53:06.582 Remux::FindDescriptors> Scanning wtv for streams...
2013/09/12 22:53:07.417 Parse> Guid: 0 took 0.84 sec, it was attempted 417 times
2013/09/12 22:53:07.417 Parse> Guid: 1 took 0.00 sec, it was attempted 0 times
2013/09/12 22:53:12.417 Parse> a/v streamdescriptors found in: 5.00 sec
2013/09/12 22:53:12.417 Parse> total descriptor parse time: 5.84 sec

On a related note, I have got the pvr.wmc addon working with XBMC Gotham and submitted the code for that to Krusty, so he might be able to post up a addon build for those wanting to run Gotham nightly builds etc. Unfortunately the channel change on the XBMC side doesnt seem to be improved, whereas from what I was digging through I was expecting that some FFMpeg changes from FernetMenta and Margro etc which were included in Gotham, were meant to speed things up. This is just from a seat of the pants opinion though, I havent got any actual timings on teh XBMC side nor have I gone back to Frodo and tried things again there etc

Looks like we were both thinking the same thing. I'm getting an average of 4 seconds with QAM (going from one qam channel to another was even quicker) and 6.5 with Digital (set-top-box)

Scarecrow, one thing I wanted to mention, while testing I constantly ran into issues using the margo build, although the channel change times were quicker with margo the video was unstable, with constant jumps and millisecond pauses. I believe someone else experienced this also.

yes the margro build only included some basic hacks to tell XBMC not to wait as long for live TV streams but that could lead to it not identifying teh stream properly, or having refdresh rate changes come through afte the stream had already started displayiong etc

upstream changes were made in ffmpeg seemingly in a more "proper" way to handle this (something about identifying PMT changes in streams whatever they are!) and from what I thought I read, this was meant to be the proper fix to this issue rather than telling XBMC to give up after a smaller amount of time

Anyway, i dont have any video issues under Gotham (basic testing only) however I cant say the front end channel changing speed (streaming etc) seems to have any improvements either... The guys over in the media portal addon is where this stuff all started (Margro is MP dev, FernetMenta is XBMC/ffmpeg) so I will have some discussions over there with them maybe

These are the pull requests that ultimately went into XBMC Gotham. By this stage they arent referring to speeding up PVR channel changes however I got to these by following bread crumbs from the Margro "fix" to set the lower timeout threshold on stream identification for LiveTV... that ultimately led to "upstream FFMPEG changes" fixing this properly (supposedly)

https://github.com/xbmc/xbmc/pull/2701
https://github.com/xbmc/xbmc/pull/1757

The interesting thing is that there are these comments "pvr clients which use this demuxer need to send pat/pmt at least when there are changes." so perhaps we actually need to do something on our side now. I guess I need to school up on all this audio/video stream stuff etc. Or just leave it krusty and Ill work on more infrastructury type changes hehe

Sounds good, you guys have made a lot of progress on this project. If you need me to testing anything I'm available. I work from home so I have the time. You can get my email from Krusty or he'll get it to me once you past things on to him.

scarecrow420 · (This post was last modified: 2013-09-12, 15:55 by scarecrow420.)

interestingly, swapping back to Frodo again, the exact same ServerWMC backend (as just released by krusty) seems to be giving me consitently 1 - 4s backend channel changes (seen from timings in log file) whereas when i was using Gotham XBMC the exact same backend was varying out to 9 seconds on some changes. I cant see how though because there arent any backend changes between the 2, and any client side changes i made for Gotham support were really just about making the new PVR API version compatilibity changes and couldnt possibly impact how the ServerWMC is processing the stream descriptors. Doesnt make sense Smile

But yeah I did over 20 channel changes on Frodo and they have all been 1 - 4 seconds at the backend.

hoopsdavis · 2013-09-12, 15:58

(2013-09-12, 15:54)scarecrow420 Wrote: interestingly, swapping back to Frodo again, the exact same ServerWMC backend (as just released by krusty) seems to be giving me consitently 1 - 4s backend channel changes (seen from timings in log file) whereas when i was using Gotham XBMC the exact same backend was varying out to 9 seconds on some changes. I cant see how though because there arent any backend changes between the 2, and any client side changes i made for Gotham support were really just about making the new PVR API version compatilibity changes and couldnt possibly impact how the ServerWMC is processing the stream descriptors. Doesnt make sense But yeah I did over 20 channel changes on Frodo and they have all been 1 - 4 seconds at the backend.

That's great. Your channels are they all QAM or are you also running from a set-top-box?

I have both and I get 3 - 4s on QAM channels, and I get from 5 - 6.5s on digital (set-top-box connected) channels.
I'm running hauppauge tuners (hd-pvr for digital channels and hauppauge 1600 for QAM)

Dilligaf · 2013-09-12, 16:24

Running HDHomeruns I have 7 channels marked as protected but the protection is copy_freely. These channels work in WMC but fail to work with in xbmc. I do NOT have a cable card or STB, logs here:
https://dl.dropboxusercontent.com/u/30655053/xbmc.log
https://dl.dropboxusercontent.com/u/3065...verWMC.log

Any ideas or any other info needed??

hoopsdavis · 2013-09-12, 16:56

(2013-09-12, 16:24)Dilligaf Wrote: Running HDHomeruns I have 7 channels marked as protected but the protection is copy_freely. These channels work in WMC but fail to work with in xbmc. I do NOT have a cable card or STB, logs here:
https://dl.dropboxusercontent.com/u/30655053/xbmc.log
https://dl.dropboxusercontent.com/u/3065...verWMC.log

Any ideas or any other info needed??

I'm not the expert but it appears the .ts file isn't being created.

Can you tell me which version serverWMC and wmc addon you're using?

Dilligaf · 2013-09-12, 17:05

Just updated to the new ones posted by Krusty, this is an ongoing problem that has been happening since release. The problem is this:

2013/09/12 10:14:13.318 SetChannel> Digital: True
2013/09/12 10:14:13.318 SetChannel> Encrypted: True
2013/09/12 10:14:13.319 SetChannel> RecorderInfo found: True
2013/09/12 10:14:13.320 SetChannel> Recorder Content Protection: PROT_COPY_FREE

They come up as encrypted yet they play on Media center, as stated before I tune Clear QAM and have no cable card or STB

hoopsdavis · 2013-09-12, 17:14

(2013-09-12, 17:05)Dilligaf Wrote: Just updated to the new ones posted by Krusty, this is an ongoing problem that has been happening since release. The problem is this:

2013/09/12 10:14:13.318 SetChannel> Digital: True
2013/09/12 10:14:13.318 SetChannel> Encrypted: True
2013/09/12 10:14:13.319 SetChannel> RecorderInfo found: True
2013/09/12 10:14:13.320 SetChannel> Recorder Content Protection: PROT_COPY_FREE

They come up as encrypted yet they play on Media center, as stated before I tune Clear QAM and have no cable card or STB

Are you getting an error message (Stream Timeout)?

Dilligaf · 2013-09-12, 17:18

It's all in the .logs:

2013/09/12 10:14:13.320 SetChannel> Recorder Content Protection: PROT_COPY_FREE
2013/09/12 10:14:13.321 SetChannel> Recorder acquired: True
2013/09/12 10:14:14.089 SetChannel> TuneRequest set
2013/09/12 10:14:14.101 StreamProc> wtv recording started in 0.79 sec
2013/09/12 10:14:14.101 StreamProc> stream output file: LiveTV_mike-PC_ClearQAM_31.1_2013_09_12_10_14_13.ts
2013/09/12 10:14:14.102 StreamProc> started remux, live stream 'ts' file: LiveTV_mike-PC_ClearQAM_31.1_2013_09_12_10_14_13.ts
2013/09/12 10:14:14.121 Remux::FindDescriptors> Scanning wtv for streams...
2013/09/12 10:14:19.386 Parse> Guid: 0 took 5.24 sec, it was attempted 2598 times
2013/09/12 10:14:19.389 Parse> Guid: 1 took 0.00 sec, it was attempted 0 times
2013/09/12 10:14:24.104 StreamProc> process start error: Stream file 'ts' does not exist, timeout: 10,000 ms reached. calling Close()

w84no1 · 2013-09-12, 17:21

(2013-09-12, 15:08)hoopsdavis Wrote:
(2013-09-12, 04:23)krustyreturns Wrote: Hi everybody,

A new version of the server and client is up on the web site. You can view the change log for details, but the main difference in the server is improved channel-change speed and scarecrow420's re-factoring of the project code. Also a number of bugs were fixed, including genre coloring and the deletion of recorded tv files.

The client addon contains a minor change too, its not necessary to upgrade the client to get it to work, but the server/client communication will be more efficient if you do.

Thanks to scarecrow420 for his changes and his cleaning up of the code. Also I want to thank hoopsdavis for his super fast testing before this release, he discovered a number of key bugs and has saved us a lot of time.

--kr

Krusty everything seems to be running great, no issues since the most recent build (1063).
I think I'll add another tuner to my system this weekend and see how the serverWMC responds, I'll touch base with you after testing.

I'm currently getting channel change speeds of Qam: 4 seconds. Digital (connect to set-top-box) 6.5 seconds.

Hoops, are you using DVBLink for your HD-PVR or the hauppauge WMC software?

hoopsdavis · 2013-09-12, 17:24

(2013-09-12, 17:18)Dilligaf Wrote: It's all in the .logs:

2013/09/12 10:14:13.320 SetChannel> Recorder Content Protection: PROT_COPY_FREE
2013/09/12 10:14:13.321 SetChannel> Recorder acquired: True
2013/09/12 10:14:14.089 SetChannel> TuneRequest set
2013/09/12 10:14:14.101 StreamProc> wtv recording started in 0.79 sec
2013/09/12 10:14:14.101 StreamProc> stream output file: LiveTV_mike-PC_ClearQAM_31.1_2013_09_12_10_14_13.ts
2013/09/12 10:14:14.102 StreamProc> started remux, live stream 'ts' file: LiveTV_mike-PC_ClearQAM_31.1_2013_09_12_10_14_13.ts
2013/09/12 10:14:14.121 Remux::FindDescriptors> Scanning wtv for streams...
2013/09/12 10:14:19.386 Parse> Guid: 0 took 5.24 sec, it was attempted 2598 times
2013/09/12 10:14:19.389 Parse> Guid: 1 took 0.00 sec, it was attempted 0 times
2013/09/12 10:14:24.104 StreamProc> process start error: Stream file 'ts' does not exist, timeout: 10,000 ms reached. calling Close()

I was getting the exact same thing on one qam channel. Krusy made some changes on wmc_addon 1009 and and got it working.
Are you using addon 1009?

Dilligaf · (This post was last modified: 2013-09-12, 17:31 by Dilligaf.)

(2013-09-12, 17:24)hoopsdavis Wrote: I was getting the exact same thing on one qam channel. Krusy made some changes on wmc_addon 1009 and and got it working.
Are you using addon 1009?

Yes, just updated today. I overwrote the existing, maybe I'll try deleting existing.

EDIT: deleting existing pvr.wmc and then copying new from 1009 made no difference.

hoopsdavis · 2013-09-12, 17:32

Check your PM