Hic-ups every 30 secs

[capone]

The default quality setting for live is VBR of 3200-7000 or something like that. I was wondering if anyone had it set to CBR, and tried a sane level like something in the 5000s.

[ram4x4nut]

I've tried it with several CBR rates, even as low as 3500 and it still has the 30 second hicups. Again, this problem, as stated, only happens when watching live tv in timeshift mode. It doesn't happen when watching a program that is currently being recorded. That being said, it seems that during timeshift there is something goin on that doesn't happen when watching a tv show that is being recorded.

[ken]

Its pretty much the same, but no not exactly. The only difference is it checks the date time on a file every thirty seconds, but I've looked at that bit of code very very carefully, but I dont see how this check could be causing this CPU spike some people a reporting.

Sub,
Is there any way to remove or stop the timeshift from checking the date time on a file every thirty seconds? Its seems to me that if that could be done then that would be one more avenue not to travel down to finding a resolution.

Ken

[sub]

Is there any way to remove or stop the timeshift from checking the date time on a file every thirty seconds? Its seems to me that if that could be done then that would be one more avenue not to travel down to finding a resolution.

Yes, I've added an option to remove this for the next release. It'll break other things, but it'll at least let us try it without this logic.

[ram4x4nut]

I can beta test it if you want.

[ken]

Thats a great idea ram. Thanks for offering up your equipment for testing. I don't like the idea of a new release if its going to break other things.

[sub]

I don't like the idea of a new release if its going to break other things.

It'll be an option you have to enable in config.xml, and wont break things unless you specifically enable it.

[wtg]

Count me in as a beta tester.

[capone]

If it's not giving anything away, what is the DB check that it does? I'm just interested partly from all this discussion, and partially because I obvoiusly interested in GB as a whole program.

As a system w/o the problem, I couldnt see a spike of any kind. But when watching TS, my avg usage is 60-80%, so is it's there, it's not making a dent.

Does everyone w/ this problem have XP in common? I'm just thinking of things I have turned off as I have gone, and always do. This really still strikes me as an XP/Win thing that is just acting on GB's activity, and not GB acting badly.

What I'm thinking of is things like write caching on HDs, NTFS Time Stamps enabled, Cache system (network or desktop), Indexing, etc. Other things would be it unnecessarialy checking other drives, espcially CD/DVD, or the LAN/WAN. Also if there was more than one drive, and power savign was set to aggressivly, it may be waking up sleeping drives (I had this causing a hiccup, so I turned off HD sleep altogether, both in Win and in the bios).

I don't think GB is doing anything wrong, but I think it is making Windows do something unncessary, unintentionally.

[sub]

If it's not giving anything away, what is the DB check that it does?

Its trying to determine if any other process has updated the recording schedule since it last checked. It used to do re-read the pending recordings from the RECORDING_SCHEDULE table automatically every thirty seconds to check this, but even several releases ago a couple of users like jsteele were reporting this thirty second hiccup, so I added a hack to minimize any overheads associated with this processing by not bothering to load the table unless I could see that some other external process had updated the database (indicated by changed file date/time). Obviously this act of reading the pending recordings from RECORDING_SCHEDULE was not the cause, since it still does it even when this logic is not called. This also makes me think it is not the process of checking the date/time, since it did this before the release that included this datetime check. It may be some overheads associated with '.net remoting' which is used to make the call from the client to the server.