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

[CathodeRay]

Back to square one, I'm afraid. Rebooting results in MySQL taking minutes to start, tvservice fails to start. I wonder if the MyISAM to innoDB conversion was also in effect a repair, that got wiped out by MP once it ran again.

 

[mm1352000]

@Lehmden
I disagreed with your post because the log files have shown that your assumptions were wrong.

You originally said:

MySQL is not ready fast enough on system start. It tells the system it is ready, but it still isn't

As we have seen, MySQL is not telling the system it is "ready". In fact, the system event log shows that Windows recognises that MySQL is hanging (ie. not "ready" as you said) and therefore intentionally does not start the TV service. That's very different to what you described.

is making me pretty sure it is exactly the same issue I always had as those are exactly the same observations I always made.

With the greatest respect, I've seen you say this in several threads now, and it is starting to really bother me for two reasons:

1. Same observations does not mean same problem.
2. Your assessment of the problem you had was shown to be wrong. You had the same issue as here (ie. MySQL hanging or failing to start => TV service failing to start). -->LINK<--.

So, I'm asking you to please stop spreading this misinformation and confusion.

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...

As above, I reject your assumptions based on the log files I have seen in this thread and log files you've provided yourself.

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...

That's a discussion for a different thread. Every option has strengths and weaknesses, and those should be considered for the application context.

Since I'm using MP2 with SQLite as DB engine I didn't had a single failure with TV Engine at all...

I understand that you're a fan of MP2 and SQLite, but these kinds of statements don't prove anything. That's your opinion/experience and I accept it. However, other people have different opinions/experience. For example, I can tell you I've been using MySQL for the whole time I have used TV Server, and I don't recall a single failure with it either. Who is right? Maybe both of us; maybe neither of us. I'd rather focus on helping the OP.

 

[mm1352000]

@CathodeRay
@Vasilich
I'm not sure that I would have advised a MyISAM to InnoDB conversion. Unfortunately I was asleep and so couldn't say anything until now.

Did anybody bother to check the MySQL log files as previously suggested?

I wonder if the MyISAM to innoDB conversion was also in effect a repair, that got wiped out by MP once it ran again.

No, it isn't.

I'd also like to point out that it would be wrong to assume that a repair always fixes problems successfully... even if MySQL says it has.

Like I said previously, I'd be looking at MySQL log files now, and if nothing stood out I'd be exporting my channels, dropping and recreating the DB, then reimporting.

 

[CathodeRay]

I realise the MyISAM to innoDB conversion isn't a repair per se, the question I had was whether re-writing the tables (the filesizes get much larger after the conversion) in effect amounted to a repair. The fact is that, immediately after the conversion, but not subsequently, MySQL and tvserver started normally. The implication is that the conversion changed something for the better, but running MP then corrupted it again. I also appreciate when a bit of computer code reports 'All OK' that can sometimes mean 'All pigs fed and ready to fly'. The proof, as another phrase has it, is in the pudding. If MySQL hangs on starting then 'All is Not OK', full stop.

As mentioned earlier, I've already done the drop database routine (I didn't bother to export the data in case it was somehow corrupt) and then recreated mptvdb by running tv-config, rescanning for channels etc. By default, MP points to a system partition recordings folder which I have changed to one on another partition, so I had to reimport my recordings after pointing MP to my recordings folder. The newly created mptvdb made no difference.

The MySQL log files don't reveal much. Here are the entries for yesterday evening and this morning:

150813 20:16:47 [Note] Plugin 'FEDERATED' is disabled.
150813 20:18:42 InnoDB: Started; log sequence number 0 6911736
150813 20:18:42 [Note] Event Scheduler: Loaded 0 events
150813 20:18:42 [Note] 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)
150813 20:19:51 [Note] C:\Program Files\MySQL\MySQL Server 5.1\bin\mysqld.exe: Normal shutdown

150813 20:19:51 [Note] Event Scheduler: Purging the queue. 0 events
150813 20:19:51 InnoDB: Starting shutdown...
150813 20:19:52 InnoDB: Shutdown completed; log sequence number 0 6911746
150813 20:19:52 [Warning] Forcing shutdown of 1 plugins
150813 20:19:52 [Note] C:\Program Files\MySQL\MySQL Server 5.1\bin\mysqld.exe: Shutdown complete

150813 20:21:38 [Note] Plugin 'FEDERATED' is disabled.
150813 20:23:33 InnoDB: Started; log sequence number 0 6911746
150813 20:23:33 [Note] Event Scheduler: Loaded 0 events
150813 20:23:33 [Note] 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)
150813 22:49:09 [Note] C:\Program Files\MySQL\MySQL Server 5.1\bin\mysqld.exe: Normal shutdown

150813 22:49:09 [Note] Event Scheduler: Purging the queue. 0 events
150813 22:49:11 [Warning] C:\Program Files\MySQL\MySQL Server 5.1\bin\mysqld.exe: Forcing close of thread 2 user: 'root'

150813 22:49:11 [Warning] C:\Program Files\MySQL\MySQL Server 5.1\bin\mysqld.exe: Forcing close of thread 1 user: 'root'

150813 22:49:11 InnoDB: Starting shutdown...
150813 22:49:13 InnoDB: Shutdown completed; log sequence number 0 7011219
150813 22:49:13 [Warning] Forcing shutdown of 1 plugins
150813 22:49:13 [Note] C:\Program Files\MySQL\MySQL Server 5.1\bin\mysqld.exe: Shutdown complete

150814 7:22:17 [Note] Plugin 'FEDERATED' is disabled.
150814 7:24:12 InnoDB: Started; log sequence number 0 7011219
150814 7:24:12 [Note] Event Scheduler: Loaded 0 events
150814 7:24:12 [Note] 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)

The only [Warnings] (which have been around for ages, from long before the problems started last week) are

Forcing close of thread x user: 'root'
Forcing shutdown of 1 plugins

but as I say these aren't new. But then again, maybe 'forcing close/forcing shutdown' is what does the damage?

Other parts of MP use sqlite successfully, and Lehmden reports using it with MP2 by implication with tvserver. I wonder if it is possible to use it with tvserver in MP1, ie get shot of that blasted MySQL once and forever?

 

[mm1352000]

I realise the MyISAM to innoDB conversion isn't a repair per se, the question I had was whether re-writing the tables (the filesizes get much larger after the conversion) in effect amounted to a repair.

I'm not a MySQL expert. I would guess the answer is "no"... but what is the point of your question? If we knew that there is or was something wrong with the TV Server database that was causing the slow start then it makes sense. However, we don't know that there is something wrong with the TV Server database, or that the TV Server database has anything to do with the MySQL slowness. In other words, it seems like you're assuming that the TV Server database is somehow causing the problem, but we don't actually have any proof for that.

The fact is that, immediately after the conversion, but not subsequently, MySQL and tvserver started normally. The implication is that the conversion changed something for the better, but running MP then corrupted it again.

I'm sorry I don't think there is enough evidence to make that statement either.

If you had repeatedly stopped and started MySQL independently after performing the change, and it started quickly each time... and then you started MP/TV Server and MySQL reverted to the slow behaviour... that would imply that MP or TV Server was doing something that messed with MySQL.

The newly created mptvdb made no difference.

This reinforces my point: it seems like something is wrong with the MySQL "engine", independent of the databases, database contents etc.

The MySQL log files don't reveal much. Here are the entries for yesterday evening and this morning:

Those log files are not very verbose. You should be able to set the log level/verbosity lower so that you get more detail. Additionally I think there are at least InnoDB engine logs that should also be checked.

Side question: how large are the log files? If they're very large, it may be a good idea to purge them.

Other parts of MP use sqlite successfully, and Lehmden reports using it with MP2 by implication with tvserver. I wonder if it is possible to use it with tvserver in MP1, ie get shot of that blasted MySQL once and forever?

It isn't possible to just replace MySQL with SQLite without additional changes.

 

[CathodeRay]

what is the point of your question?

Since we're so keen on observation here rather than guessing, my observation was that MyISAM to innoDB was the only action that immediately caused mysql to start normally (and so tvserver). Something had changed, and the only thing that had changed was the conversion. Call it a conversion rather than a repair, but something changed, and so the key question is what changed to allow mysql to start normally?

If you had repeatedly stopped and started MySQL independently after performing the change, and it started quickly each time... and then you started MP/TV Server and MySQL reverted to the slow behaviour... that would imply that MP or TV Server was doing something that messed with MySQL.

Actually, that is what happened. I'm not a complete idiot. I did start and stop the mysql service several times - I do know about the importance of repeatability (and anyway I couldn't believe it was working!) - and each start (and stop) took two or three seconds, but once I started tvserver and it had done its mischief it was back to two minute mysql starts and tvserver not starting.

This reinforces my point: it seems like something is wrong with the MySQL "engine", independent of the databases, database contents etc.

Not necessarily. The mptvdb was created by MP's tv-config, tvserver was running (obviously).

Side question: how large are the log files? If they're very large, it may be a good idea to purge them.

I've already done this. The ib_logfiles were around 50MB but that seems to be set by mysql, the [pc-name].err file was 555KB, now 2KB. Purging these files made no difference.

Since all the tables are now innoDB tables, I can't convert them to innoDB again (though I suppose I could convert them back to MyISAM and then back to innoDB but I might lose the will to live before fininishing that) to repeat the observation that converting to innoDB does cause a normal mysql start until such time as tvserver acts on mptvdb. Doing the conversion table by table in a GUI is safer but tedious. I guess there is a (set of)sql commands that will do it but as we all know one typo and it's sql hell.

I will see what I can do to replicate the mysql quick start > run tvserver > mysql slow starts behaviour.

Pity a change to sqlite isn't a straight forward option.

 

[HTPCSourcer]

In case that you would like to try alternatives: I am using MS SQLExpress since my very beginning with MePo and never had any database problems - just like mm.

I just wanted to make you aware of this option, which would nonetheless mean that you would have to go through another install cycle for TVServer. Don't forget to export your TV channels first.

 

[CathodeRay]

OK, MP may be off the hook (for now...). More experimental data:

Reboot pc: mysql starts slow
Run auto-repair (it's in a batch file now...): sometimes but not always this allows fast mysql starts - no obvious pattern/reason
Confirm yet again mysql starts are fast
Reboot pc: mysql starts slow

At no time in the above sequence (repeated more than once) was tvserver or MP started, so hard to blame MP when it hasn't been in the game... More specifically, it appears to be the Windows shutdown closing of the mysql service that fries it.

HTPCSourcer: thanks for the info/suggestion. My trouble is that for better of for worse (probably the latter) I have tinkered with some MP .dlls (both tv engine ones and some others) and skin (display) files to customise them (mainly context menus) so I can do things inside MP when it's running which means if I do a TVServer reinstall I will have to pre-save my custom .dlls and replace them after the reinstall. I'm also not sure how to do a partial reinstall (of just TVServer and its database) and memories of that deploy tool thingy are dark and shrouded memories of red shirts and brown trousers. I may yet have to get my overalls on though because I'm getting to the end of what is reasonable in trying to get mysql to behave itself.

 

[mm1352000]

Please can you increase the verbosity in the MySQL log so we can see additional detail about the delay, and also check the InnoDB log to see if it reveals anything.

One other random question...
Is the IP address for your PC statically assigned (ie. fixed) in the NIC properties, or is it assigned by your router?

 

[CathodeRay]

Not sure how to increase the mysql log verbosity - a line in my.ini? Googling anything to do with mysql is google hell, trillions of links to either impenetrable pages or goofy forums that fizzle out.

The innoDB logs are cryptic, probably binary, and unreadable by mere mortals.

One other random answer: not sure about the IP address - networks do my head in. The HTPC as you know is called media-pc, and that's the name I use. There's no router in the setup. Most of the time the HTPC isn't connected to another computer; when it is, it is via an ethernet cable (cross-over cable?) between two PCI network cards, one in each PC. The only reason for networking it at times is because the only display connected to the HTPC (I did say I was ancient) is an old CRT TV, which means text is difficult to read on that display, but if I map the relevant folder to my normal PC, then it's easier to read text files. But, most of the time, the HTPC is not connected to another computer.[DOUBLEPOST=1439552056][/DOUBLEPOST]I've also had a look at the MP wiki on database engine choice. As is sometimes the case, the information is somewhat limited, incomplete and/or situation specific. My original deploy thingy favoured the 2005 version of MS SQLExpress but online it now seems to be one of two 2008 versions. To cover the possibility that MySQL never gets fixed, I am considering going over to MS SQLExpress but which version? Also, I wonder if it is possible to install MS SQLExpress and then tweak my existing MP installation to use it rather than MySQL? I have these bad memories of MP installations taking forever and not working... Years ago I bought a version of ShowShifter when it was around and nothing that I have tried since has got even close to matching the simplicity of its installation, and the fact it just works - still does, in fact, but it can only do one tuner, and its EPG now needs a third party work-around to get it filled with program data.