Occasional pauses in some DBV-T LiveTV (1 Viewer)

[dale77]

In my case, I'm using a single cable direct from the UHF aerial to the tuner. No splitters or amps.

 

[Baboonanza]

I have exactly the same issues. The pauses are pretty infrequent for me usually so I can live with it, but it's annoying when it happens so it would be nice to get it fixed.

I'm running:
Win 7 64bit
MP 1.1 RC1
SAF 4.0
PEAK Dual Tuner DVB-T card
ATi HD4200 (785g chipset integrated)

I didn't have this problem before upgrading from MP 1.1 BETA to RC1. When I upgraded I did a complete rebuild (including re-installation of Win 7). The only other differences was that previously I had installed all the codecs seperately, this time I used SAF 4.0, but the codecs I use for TV should be the same (Cyberlink I think) and moved from Catalyst 10.1 to 10.2.

 

[deadmonty]

Baboonanza, as an aside to this issue, how well does the Peak card work with Win7? There are reports on other threads that it does not work well under Win7 - takes ages to initialize and ages to zap between channels. Is this still the case?

 

[Baboonanza]

Depends what you mean by 'ages'. Initialisation is pretty slow, 5-7 seconds I would guess. Channel changes are ok, 2-3 seconds in MP and slightly faster in WMC. I navigate using the guide rather than flicking channels so that's fast enough for me.

I wanted something cheap but functional to tide me over until DVB-T2 cards come out (and to provide extra recording streams afterwards). I'm pretty happy with it, especially for the £40 price.

 

[dale77]

The pauses are pretty infrequent for me usually so I can live with it, but it's annoying when it happens so it would be nice to get it fixed.

Exactly my situation.

 

[AberDino]

I concur that there are holes in the stream but is it possible the server is failing to write the entire data stream rather than it being a reception problem.

STuNZ, I think you could be on the right track here. Like many others I too notice stutters from time to time and I have video/audio continuity errors in my tsreader logs. In my case I know reception quality should not an issue (DVB-t and DVB-s). Yesterday I was watching TV when I noticed a brief stutter. I jumped 30 seconds back, and when the same scene was played there was no stutter at all. This suggests to me that the broadcast was recorded OK in the timeshift file on the server (no issues with reception), but somehow there was a glitch relaying that data to the client.

 

[romuz]

I concur that there are holes in the stream but is it possible the server is failing to write the entire data stream rather than it being a reception problem.

STuNZ, I think you could be on the right track here. Like many others I too notice stutters from time to time and I have video/audio continuity errors in my tsreader logs. In my case I know reception quality should not an issue (DVB-t and DVB-s). Yesterday I was watching TV when I noticed a brief stutter. I jumped 30 seconds back, and when the same scene was played there was no stutter at all. This suggests to me that the broadcast was recorded OK in the timeshift file on the server (no issues with reception), but somehow there was a glitch relaying that data to the client.

check streamingserver logs for that time, do u have "seeking beyond the end" errors in it for that period?
Because i have same problem sometimes. Seeking back can cure it.

 

[Baboonanza]

It has also occurred to me to add my timeshifting folder as an excemption in my security software (Microsoft Security Essentials). It's possible that it was introducing a slight delay, particularly on new file creation.

I've only watched 30mins since the change, but there were no stutters. More testing needed though.

 

[AberDino]

check streamingserver logs for that time, do u have "seeking beyond the end" errors in it for that period. Because i have same problem sometimes. Seeking back can cure it.

romuz, good point, I'll check over the next couple of days.

 

[STuNZ]

I concur that there are holes in the stream but is it possible the server is failing to write the entire data stream rather than it being a reception problem.

STuNZ, I think you could be on the right track here. Like many others I too notice stutters from time to time and I have video/audio continuity errors in my tsreader logs. In my case I know reception quality should not an issue (DVB-t and DVB-s). Yesterday I was watching TV when I noticed a brief stutter. I jumped 30 seconds back, and when the same scene was played there was no stutter at all. This suggests to me that the broadcast was recorded OK in the timeshift file on the server (no issues with reception), but somehow there was a glitch relaying that data to the client.

Possibly not the same issue then as I see the same stutter again if I go back and replay with timeshift or from a recording.

What I have found since is that simply scrolling up and down in moving pictures or the main menu with TV playing, similar stutters occur and are reproducable in the recording. TS reader confirms discontinuity errors for those same times so I conclude from that it's not a reception problem, but rather a system constraint blocking the complete datastream being written to the recording or timeshift. I'm using StreamedMP which loads fanart when scrolling up and down which would obviously spike system resource consumption in a few places. CPU never goes over 20% so I'm wondering if the PCI or some other bus is getting over subscribed. And what triggers it on the occassions when I'm not messing around on menu loading lots of fan art as I don't want this to be considered a StreamedMP thing. It is just a way I can force the same discontinuity in recordings happen sporadically on their own but did not occur on 1.02 on XP

I've since gone back to 1.02 on XP and I don't see the same behaviour on the same hardware so I'm wondering either what has changed in RC1 to increase internal bus utlisation or is the swap from XP to Win7 a factor?