TV Service doesn't start automatically with XP (1 Viewer)

[CathodeRay]

"Just a quick question as I look through the tv.log..." These times fit with me turning off the pc, the later time after watching the news, the earlier ones were me testing reboots to see whether the tvservice not starting problem was persistent (which it is...).

As noted earlier, I did both run mysqlcheck --auto-repair (reported all tables OK) and drop database (and rebuild from scratch) earlier, but the tvservice not starting problem continues.

"13/08/2015 10:14:42";"Service Control Manager";"(0)";"Error";"The MySQL service hung on starting.";"3221232494"
"13/08/2015 10:14:42";"Service Control Manager";"(0)";"Error";"The TVService service depends on the MySQL service which failed to start because of the following error: %After starting, the service hung in a start-pending state.";"3221232473"

Even I can understand what that is saying(!) and is clearly the proximate reason why tvservice isn't starting. The odd things are now:

(a) services.msc shows MySQL has started (maybe it retries?). As noted earlier it does sometimes seem slow to start (on opening services.msc it shows 'starting' for quite a while then goes to started).

(b) why is MySQL 'not happy'? As noted I've checked and rebuilt mptvdb, and also done a repair install on MySQL Server. Maybe time to ditch MySQL and go for another flavour of database - perhaps SQLExpress as suggested by Lehmden? Is there any consensus on what is the best db backend for MP 1.2?

Best wishes

CathodeRay

 

[mm1352000]

"Just a quick question as I look through the tv.log..." These times fit with me turning off the pc, the later time after watching the news, the earlier ones were me testing reboots to see whether the tvservice not starting problem was persistent (which it is...).

Okay. From the log files it looks like the way that you're turning off the PC is not "safe". In other words, Windows doesn't appear to be shutting down (and thereby stopping the TV service etc.) in a proper fashion.
How exactly are you turning off or restarting? I mean, are you using the Windows start menu, physically pressing the power or reset button on the PC case, or...?

As noted earlier, I did both run mysqlcheck --auto-repair (reported all tables OK) and drop database (and rebuild from scratch) earlier, but the tvservice not starting problem continues.

Yes, that's understood.
My suspicion at this point is that your "apparently-unsafe" shutdown/reboot procedure is negatively affecting MySQL on each shutdown/reboot. So, the previous check + autorepair is superseded.

(a) services.msc shows MySQL has started (maybe it retries?). As noted earlier it does sometimes seem slow to start (on opening services.msc it shows 'starting' for quite a while then goes to started).

Speculation here... but I would guess that Windows asks MySQL to start, waits awhile, thinks MySQL has hung because it hasn't completed starting yet, logs the error, doesn't start TV service as a result... and then carries on with booting. Eventually MySQL finishes whatever it is doing and thereby enters the "running" state. Finally, when you come along and check, you think everything is fine and wonder why TV service hasn't started.

(b) why is MySQL 'not happy'? As noted I've checked and rebuilt mptvdb, and also done a repair install on MySQL Server.

Well, the question about why MySQL is not happy is the million dollar question.
As above: at this point it looks like it could be because you're not shutting it (both MySQL and the PC) down cleanly on a frequent basis. I assume you're aware that it is not reasonable to expect to be able to hard-power-off (effectively: pull the plug) a PC without consequences? It looks like that's what you're doing... and therefore I'm not surprised to see that MySQL is suffering. There could well be other consequences too that I haven't noticed.

If the problem persisted after changing your shutdown procedure I would be running the check + auto-repair again, and checking the MySQL logs to see what it is doing that is taking so long.

Maybe time to ditch MySQL and go for another flavour of database - perhaps SQLExpress as suggested by Lehmden? Is there any consensus on what is the best db backend for MP 1.2?

In my opinion swapping DBs would be premature... and possibly pointless if the problem is your shutdown procedure.

 

[mm1352000]

Looking at the MySQL logging in the application event log:
[collapse]
"13/08/2015 09:34:08";"MySQL";"(0)";"Information";"The description for Event ID '-1073741724' in Source 'MySQL' cannot be found. The local computer may not have the necessary registry information or message DLL files to display the message, or you may not have permission to access them. The following information is part of the event:'Plugin 'FEDERATED' is disabled. '";"3221225572"
"13/08/2015 09:34:48";"ESENT";"General";"Information";"wuauclt (2348) The database engine 5.01.2600.5512 started.";"100"
"13/08/2015 09:34:48";"ESENT";"General";"Information";"wuaueng.dll (2348) SUS20ClientDataStore: The database engine started a new instance (0).";"102"
"13/08/2015 09:35:43";"SecurityCenter";"(0)";"Information";"The Windows Security Center Service has started.";"1800"
"13/08/2015 09:36:04";"MySQL";"(0)";"Information";"The description for Event ID '-1073741724' in Source 'MySQL' cannot be found. The local computer may not have the necessary registry information or message DLL files to display the message, or you may not have permission to access them. The following information is part of the event:'Event Scheduler: Loaded 0 events '";"3221225572"
"13/08/2015 09:36:04";"MySQL";"(0)";"Information";"The description for Event ID '-1073741724' in Source 'MySQL' cannot be found. The local computer may not have the necessary registry information or message DLL files to display the message, or you may not have permission to access them. The following information is part of the event:'C:\Program Files\MySQL\MySQL Server 5.1\bin\mysqld.exe: ready for connections.
Version: '5.1.38-community' socket: '' port: 3306 MySQL Community Server (GPL) '";"3221225572"[/collapse]

...that's taking a very long time to start. Approximately 2 minutes in total. 40 seconds for the DB engine to start up and 76 seconds for the DB to come online. That's really unusual in my experience.

As suggested above, I'd be auto-repairing again... checking the startup time after that... then checking the MySQL log if that is not sufficient.

 

[CathodeRay]

'Not safe' - reminds me of Laurence Olivier asking Dustin Hoffman 'is it safe?'.

Normally I shut down the PC by taking bolt croppers to the power cord - simple, but effective, though it does cause havoc with the rest of the domestic electrics and I've lost my eyebrows once or twice. Seriously though: I just physically press the power on/off button. The PC makes the using shutting down noises and screens and turns off. I don't necessarily make a point of closing MP first, on the basis that Windows should shut things down gracefully - but maybe it doesn't. I'm not sure using the power on/off switch can be equated to 'pull[ing] the plug' - this being more like a power cut (or using those bolt croppers). My understanding was that Windows should close what needs to be closed before it itself shuts down. Indeed, you sometimes on some machines (not the one in question) see a message box saying Windows is closing xxx or words to that effect and sometimes it stops shutdown at that point if xxx doesn't close.

I do take the point about an unsafe shutdown undoing a prior --auto-repair. Also your speculation (sometimes we all speculate a bit!) makes good sense, and fits with my observation that the MySQL service takes what seems like a long time in the 'starting' state. Just read your 'very long time to start post' - all this fits together.

From what I see on the screen/hear during shutdown, going through Alt+F4 or 'Turn off computer' > 'Turn off' initiates exactly the same procedure as using the front power switch. I wonder what else I can do when shutting down the PC to improve the shutdown process so when Larry asks me 'is it safe? I can answer 'yes'.

I agree changing the db backend would be premature but asked just in case I had missed something as in another backend was now preferred. As far as I understand it MySQL is still first (equal?) choice.

 

[mm1352000]

,,,and I've lost my eyebrows once or twice.

I didn't know how else to describe it.

Seriously though...

Yes, I generally agree with what you said here.
MediaPortal log does show:
2015-08-12 22:41:26.625000 [Info.][MPMain(1)]: Main: Windows is requesting shutdown mode

It's just that what I see happening in the tv.log doesn't match. I see the tuner/channel (BBC FOUR) stopped (which corresponds with the MP log)... but then the EPG grabber kicks off as if the system is not powering off... and then there's the MySQL exception/error... and silence.

It's possible that this - the starting of the EPG grabber, even though the system - is an artefact/bug in the now-quite-ancient version of MP you're using. It'll be 4 years since MP 1.2.2 was released in December, and I just don't remember the details of issues that were current at that time. However, I would have thought if it were, this would have impacted you previously.

From what I see on the screen/hear during shutdown, going through Alt+F4 or 'Turn off computer' > 'Turn off' initiates exactly the same procedure as using the front power switch. I wonder what else I can do when shutting down the PC to improve the shutdown process so when Larry asks me 'is it safe? I can answer 'yes'.

I'm sorry. I don't have a response. Your procedure should be okay...

I agree changing the db backend would be premature but asked just in case I had missed something as in another backend was now preferred. As far as I understand it MySQL is still first (equal?) choice.

MySQL and SQL Server are the only choices supported for MP1.
Some people will recommend SQL Server because it traditionally doesn't seem to suffer from the corruption experience you had. However, I consider them effectively equal, as you said.

 

[CathodeRay]

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.

 

[Vasilich]

what you can try is convert all tables in mptvdb from myisam engine to innoDB engine The later is a transactional DB so it doesn't need repairing. Make backup of your DB before experimenting though.
(I myself use it on my production system with MP 1.2.3)

 

[Lehmden]

Hi.

how you've been able to come to that conclusion

Because of this:

TV service not starting automatically with Windows

and this:

whether this is tvservice trying to start before MySQL is running, but shouldn't Windows take care of that ie not try to start tvservice until MySQL has conformed it is running

and finally this...

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.

is making me pretty sure it is exactly the same issue I always had as those are exactly the same observations I always made. I can proof this was not fixed at least until MP 1.10 and MySQL 5.6 as those are the last versions I had used... It's more the opposite way around, it was getting worse with every new version of TVServer...


By the way, it would be pretty cool if TVE 3.5 will have SQLite as default Database Engine right from the start so such kind of issues simply can't happen at all...
Since I'm using MP2 with SQLite as DB engine I didn't had a single failure with TV Engine at all... It never fails to start, it never hung on standby or wakeup it never missed a scheduled recording, 100% rock solid... It's the same piece of software than the MP1 TV server but it is much more reliable working with SQLite, at least on my system. This makes me guess, a MySQL DB server is not the best choice to provide the few tables needed for TVE...

 

[CathodeRay]

Hi Vasilich

Doing things to MySQL databases always feels a bit like holding a stick of dynamite in one hand and a lighted match in the other and hoping nothing goes wrong. However I have converted all the tables in mptvdb from MyISAM to innoDB (I used HeidiSQL, have to do each table individually, can be done using sql but more chances for errors through typos) after backing up mytvdb. No error notices, and the table sizes increased (as I believe is to be expected). I haven't changed anything else, MyISAM is still the default engine in my.ini for example, but I think that only kicks in for new tables as they are created. On first reboot MySQL had started by the time I had services.msc open and tvservice started soon after, MP started normally and all the expected data - channels, EPG, Recorded TV etc was as expected. So I think your suggestion may have fixed the problem - if so many many thanks.

Perhaps (I'm speculating here) when I did the auto-repair (or even more so the database rebuild, given the setting in my.ini), I managed to end up with MyISAM tables when previously I had had innoDB tables? Not sure how or why unless I changed them to inniDB so long ago I've forgotten, but it seems a possible explanation: until last week they were innoDB, then got reset to MyISAM.

Lehmden - "it was getting worse with every new version of TVServer..." - this is one of the reasons why I tend to stick with the old (ancient) version I have. I tried upgrading a couple of times and things got worse not better. If it works, why fix it... I also agree that MySQL tends to be the database from Hell (there are other setting I have to use it in, and it often provides lots of fun and games) whereas sqlite more often than not just simply works.

Many thanks to all who have so generously helped sorting out this problem which I hope is now fixed.

CathodeRay

 

[Vasilich]

until last week they were innoDB, then got reset to MyISAM

no, the default engine for MP was MyISAM (at least until MP 1.9), so something different happened on your side last week.
But i'm glad i could help and you have working MP again