Normal
I've just done the following:1. rebooted, gone to services.msc and mysql shows 'starting', tap F5 every few seconds and yes it does take approx two mins to get to 'started'.2. run an --auto-repair (reports all OK) and then in the same command prompt window done net stop mysql (success) and then net start mysql - and it starts in a few secs (about 2-3s). So its the boot start that's slow.3. stopped mysql manually and then rebooted: mysql has started by the time services.msc can display it and tvservice starts !!!4. don't stop mysql manually then reboot: mysql service slow to start, tvservice doesn't start.So it seems that somehow Windows is doing something to mess up mysql/mptvdb is the mysql service is running as Windows does a ('normal') shutdown. This appears to be a new problem - recall that until the db corruption incident tvservice would start normally.A workaround is a batch file to shut down the pc with net stop mysql in the batch file...but its seems a bit of a kludge. I'd rather Windows behaved itself and shutdown the PC gracefully...mm1352000: Just seen your latest post (and thanks for all your help): The EPG grabber: I do wonder whether that may be it? I have it set to collect when idle (and not when recording/timeshifting) because in the past I perceived/suspected EPG grabbing caused stuttering live tv/playback when it kicked it. So maybe what happens is this. MP shuts down but tvservice is still running and as it is set to collect when idle, because MP is not active, it kicks in, but is doomed, because Windows is about to close down, but the grabber manages a final jab at mptvdb, and in so doing messes it up? On balance, I probably do shutdowm MP before turning off the PC (its only one button press on the remote, to be honest I haven't thought about it too much) so this brief 'idle' period could perhaps be the explanation. Even if I don't shut down MP before shutting down the PC, this brief idle period might still happen.The test is probably to set EPG grabbing on only when timeshifting/recording, and off when idle, and see what happens, both to mysql/mptvdb and whether the stuttering is still a problem. I wonder whether when I rebuilt the mptvdb from scratch I put slightly different timeout/refresh timings in tvconfig - but different enough to cause this new problem? I'm sure there is a clue somewhere in the fact the problem started soon after the db corruption episode, and wasn't present before.As far as ancient software goes, I'm a self confessed slow adopter, on an if it works (well, it usually does), why fix it basis. I'm also a bit of a tinkerer, so updating usually means re-doing my tweaks. The HTPC sits in my living room, normally un-networked, the idea being it just sits there doing its stuff.[DOUBLEPOST=1439477336][/DOUBLEPOST]Just tried setting EPG grabbing on when timeshifting/recording, off when idle, no dice: mysql back to slow start, tvservice doesn't start.
I've just done the following:
1. rebooted, gone to services.msc and mysql shows 'starting', tap F5 every few seconds and yes it does take approx two mins to get to 'started'.
2. run an --auto-repair (reports all OK) and then in the same command prompt window done net stop mysql (success) and then net start mysql - and it starts in a few secs (about 2-3s). So its the boot start that's slow.
3. stopped mysql manually and then rebooted: mysql has started by the time services.msc can display it and tvservice starts !!!
4. don't stop mysql manually then reboot: mysql service slow to start, tvservice doesn't start.
So it seems that somehow Windows is doing something to mess up mysql/mptvdb is the mysql service is running as Windows does a ('normal') shutdown. This appears to be a new problem - recall that until the db corruption incident tvservice would start normally.
A workaround is a batch file to shut down the pc with net stop mysql in the batch file...but its seems a bit of a kludge. I'd rather Windows behaved itself and shutdown the PC gracefully...
mm1352000: Just seen your latest post (and thanks for all your help): The EPG grabber: I do wonder whether that may be it? I have it set to collect when idle (and not when recording/timeshifting) because in the past I perceived/suspected EPG grabbing caused stuttering live tv/playback when it kicked it. So maybe what happens is this. MP shuts down but tvservice is still running and as it is set to collect when idle, because MP is not active, it kicks in, but is doomed, because Windows is about to close down, but the grabber manages a final jab at mptvdb, and in so doing messes it up? On balance, I probably do shutdowm MP before turning off the PC (its only one button press on the remote, to be honest I haven't thought about it too much) so this brief 'idle' period could perhaps be the explanation. Even if I don't shut down MP before shutting down the PC, this brief idle period might still happen.
The test is probably to set EPG grabbing on only when timeshifting/recording, and off when idle, and see what happens, both to mysql/mptvdb and whether the stuttering is still a problem.
I wonder whether when I rebuilt the mptvdb from scratch I put slightly different timeout/refresh timings in tvconfig - but different enough to cause this new problem? I'm sure there is a clue somewhere in the fact the problem started soon after the db corruption episode, and wasn't present before.
As far as ancient software goes, I'm a self confessed slow adopter, on an if it works (well, it usually does), why fix it basis. I'm also a bit of a tinkerer, so updating usually means re-doing my tweaks. The HTPC sits in my living room, normally un-networked, the idea being it just sits there doing its stuff.[DOUBLEPOST=1439477336][/DOUBLEPOST]Just tried setting EPG grabbing on when timeshifting/recording, off when idle, no dice: mysql back to slow start, tvservice doesn't start.
