tv service not beeing loaded automatically on startup (2 Viewers)

[RicoHTPC]

Hooray! I've got it working again!
I restored an image which only differs to the one I used before by not having net.4 and imdisk installed.
But obviously one of them had caused the problems.
What suprised me a bit was that creating my ramdisk at reboot works without having imdisk installed....
Anyway.
As I now could configure my server I came across one question: is there a difference if I setup timeshift and recording paths
with unc or if I do it with rtsp?
Thx for your help guys!

 

[breese]

As I now could configure my server I came across one question: is there a difference if I setup timeshift and recording paths
with unc or if I do it with rtsp?

If you have a RamDisk, Timeshifting would be best on it
For Recordings, a direct path to an available hard drive is good. If you have a NAS, you will need to try it, remember it is added network traffic.

 

[RicoHTPC]

No you got me wrong, I've got timeshift on a ramdisk and recordings on a hdd inside my server.
On my client I am using unc paths.
Should I state unc paths inside the server config as well?

Edit: Nobody an idea?
Did I make clear what I mean? Using unc path on the client would look like \\Server\R\Timeshift no question.
And on the server config? Do I have to state \\Server\R\Timehsift as well or can I also use R:\Timeshift?

 

[breese]

Does the client have its own TV Card?
If not, (guys correct me if I am wrong, been a while sense I messed with MP1) but if you can see the TV (on the server) from the client and choose to record, it will use the Server configuration and drives to do it
Nothing needs to be done at the Client level

 

[HomeY]

is there a difference if I setup timeshift and recording paths
with unc or if I do it with rtsp?

Yes, there is. For me (on a multi-seat setup) UNC is about 25% faster with zapping then RTSP. UNC also seems more stable than RTSP on my LAN, and with the latest SMB cache fixes in the TsReader filter, it's running really sweet.

Should I state unc paths inside the server config as well?

You can't. The streaming service makes sure that both options are available, and you define it on the client(s) (as you probably have).

 

[RicoHTPC]

I realized that when using unc paths at the client but we're both talking about the paths inside the Server config, right?

 

[HomeY]

but we're both talking about the paths inside the Server config, right?

The path you define in TV Server config (for recording & timeshift folders) don't have any influence on your choice to use either RTSP or UNC on your clients
Or are you talking about other 'paths' ??

 

[RicoHTPC]

Nope, that's what I meant. Thanks for clarifying!

 

[mm1352000]

@Lehmden
Thanks for the log files.

OK, Channel Name was "Das Erste HD", the rest is sayed before.

The date/time conversion is a little tricky for somebody who doesn't care about soccer or live in Germany.
By my calculation the final started 13 July 2014 at 9:00:00 p.m. German local time, so the problem with the signal was at ~8:30pm???
From the logs it looks like there are problems with Das Erste HD at about 8:15pm so I think my guess is correct...

Now let's talk about what you saw.

First, the "all cards are busy" messages.
TV Server was frantically trying to start your world cup recording. The scheduler had reserved the tuners while trying to tune (TV Server reserves up to 4 - or is it 2, can't remember - tuners when processing a tune request). In other words, you and the scheduler were both trying to access the tuners at the same time, and only one could succeed.
[collapse]
[2014-07-13 20:15:54,394] [Log ] [17 ] [INFO ] - Controller: find free card for channel Das Erste HD
[2014-07-13 20:15:54,394] [Log ] [17 ] [INFO ] - Controller: find card for channel Das Erste HD
[2014-07-13 20:15:54,394] [Log ] [17 ] [INFO ] - Controller: got 1 tuning details for Das Erste HD
[2014-07-13 20:15:54,394] [Log ] [17 ] [INFO ] - Controller: channel #1 DVBS:tv:ARD Das Erste HD Freq:11494000 ONID:1 TSID:1019 SID:10301 PMT:0x13EC FTA:True LCN:10000 SymbolRate:22000 Modulation:Mod8Psk Polarisation:LinearH InnerFecRate:Rate2_3 DisEqc:None band:Universal Pilot:On RollOff:ThirtyFive
[2014-07-13 20:15:54,394] [Log ] [17 ] [INFO ] - Controller: card:1 type:RadioWebStream is disabled
[2014-07-13 20:15:54,394] [Log ] [17 ] [INFO ] - Controller: card:5 typevbS can tune to channel
[2014-07-13 20:15:54,394] [Log ] [17 ] [INFO ] - Controller: card:6 typevbS can tune to channel
[2014-07-13 20:15:54,394] [Log ] [17 ] [INFO ] - Controller: found 2 card(s) for channel
[2014-07-13 20:15:54,394] [Log ] [17 ] [INFO ] - AdvancedCardAllocation.GetAvailableCardsForChannel took 2 msec
[2014-07-13 20:15:54,394] [Log ] [17 ] [INFO ] - Controller: found 2 free card(s)
[2014-07-13 20:15:54,394] [Log ] [17 ] [INFO ] - AdvancedCardAllocation.GetFreeCardsForChannel took 2 msec
[2014-07-13 20:15:54,394] [Log ] [17 ] [DEBUG] - CardReservationBase.HasUserHigherPriorityThanBlockingUser: False - user 'Kirk' with prio=2 vs blocking user 'scheduler60' with prio=100
[2014-07-13 20:15:54,394] [Log ] [17 ] [DEBUG] - CardReservationBase.RequestCardTuneReservation: failed reservation tuningdetails=DVBS:tv:ARD Das Erste HD Freq:11494000 ONID:1 TSID:1019 SID:10301 PMT:0x13EC FTA:True LCN:10000 SymbolRate:22000 Modulation:Mod8Psk Polarisation:LinearH InnerFecRate:Rate2_3 DisEqc:None band:Universal Pilot:On RollOff:ThirtyFive, res id blocking=5, state=Tuning
[2014-07-13 20:15:54,394] [Log ] [17 ] [DEBUG] - CardReservationBase.HasUserHigherPriorityThanBlockingUser: False - user 'Kirk' with prio=2 vs blocking user 'scheduler60' with prio=100
[2014-07-13 20:15:54,394] [Log ] [17 ] [DEBUG] - CardReservationBase.RequestCardTuneReservation: failed reservation tuningdetails=DVBS:tv:ARD Das Erste HD Freq:11494000 ONID:1 TSID:1019 SID:10301 PMT:0x13EC FTA:True LCN:10000 SymbolRate:22000 Modulation:Mod8Psk Polarisation:LinearH InnerFecRate:Rate2_3 DisEqc:None band:Universal Pilot:On RollOff:ThirtyFive, res id blocking=6, state=TunePending
[2014-07-13 20:15:54,394] [Log ] [17 ] [INFO ] - Controller: StartTimeShifting failed:AllCardsBusy[/collapse]

Exact same thing would have happened with any version of TV Server since the card reservation system went in (~MP 1.4???).
By default the scheduler has higher user priority so would "win" over your tune requests. If you wish to change that you can do it here:
http://wiki.team-mediaportal.com/1_...n/TV-Server_Configuration/10a_User_Priorities


Now the "no signal".
This is tougher to explain. I can see that the tuner stops delivering the stream without any interaction from TV Server:
[collapse]
[2014-07-13 20:12:36,715] [79cef20] [bb0] - Recorderid 13f2 Continuity error... 7 ( prev 4 ) - bad signal?
[2014-07-13 20:12:36,715] [79cef20] [bb0] - Recorderid 13f2 Continuity error... 7 ( prev 4 ) - bad signal?
[2014-07-13 20:12:36,715] [79cef20] [bb0] - Recorderid 13f0 Continuity error... 1 ( prev 6 ) - bad signal?
[2014-07-13 20:12:36,716] [79cef20] [bb0] - Recorderid 13f0 Continuity error... 1 ( prev 6 ) - bad signal?
[2014-07-13 20:12:36,716] [79cef20] [bb0] - Recorderid 13ee Continuity error... e ( prev 9 ) - bad signal?
[2014-07-13 20:12:36,716] [79cef20] [bb0] - Recorderid 13ee Continuity error... e ( prev 9 ) - bad signal?
[2014-07-13 20:12:36,716] [79cef20] [bb0] - Recorderid 13ef Continuity error... e ( prev 9 ) - bad signal?
[2014-07-13 20:12:36,716] [79cef20] [bb0] - Recorderid 13ef Continuity error... e ( prev 9 ) - bad signal?[/collapse]

Then you stop timeshifting from MediaPortal and the series of "no signal" reports begin.

It is very odd that the tuner stopped streaming and it is equally odd that installing MP 1.6 would suddenly make the tuner start working again. I'd be interested to know if you've ever seen such a thing happen before or if it happens again.

Unfortunately your 1.6 log files don't go far enough back to see what happened immediately after you installed 1.6 over the top, so I have no idea when or why the tuner started working again. Maybe you could check your Windows event logs?
In any case, what I can say is that when a tuner just stops streaming like this without any interaction from TV Server, the things I would suspect [in this order] are signal, tuner hardware, heat, or some other system process/problem (particularly "security" software or drivers). TV Server itself wouldn't even be on my list. Maybe I'm biased, but that might tell you something about how unfair I think it would be to blame TV Server.

About signal...
I'm sure you know that weak signal can cause problems. I trust that you know whether your signal strength/quality is adequate and won't speculate about that here. Still, I have two points related to signal that you might not be aware of.
Based on the log files it looks like the driver for your tuner applies the tune request asynchronously when we run the graph. In short that means that we'll often see:
[collapse]
[2014-07-14 22:02:30,684] [Log ] [9 ] [INFO ] - dvb: RunGraph
[2014-07-14 22:02:30,862] [Log ] [9 ] [INFO ] - dvb: LockInOnSignal waiting 20ms
[2014-07-14 22:02:30,882] [Log ] [9 ] [INFO ] - dvb: LockInOnSignal waiting 20ms
[2014-07-14 22:02:30,902] [Log ] [9 ] [INFO ] - dvb: LockInOnSignal waiting 20ms
[2014-07-14 22:02:30,922] [Log ] [9 ] [INFO ] - dvb: LockInOnSignal waiting 20ms
[2014-07-14 22:02:30,942] [Log ] [9 ] [INFO ] - dvb: LockInOnSignal waiting 20ms
[2014-07-14 22:02:31,324] [Log ] [9 ] [INFO ] - dvb: LockInOnSignal ok[/collapse]

The "LockInOnSignal waiting 20ms" would be while the tuner is still tuning... and then [hopefully] it locks.
Notice it takes about 650 ms to lock here. If your tune timeout is set to 2 seconds (default) it is not impossible that you could get false "no signal" errors if the tuner takes longer to tune than normal. I'd suggest it might be a good idea to increase that tune timeout:
http://wiki.team-mediaportal.com/1_...n/TV-Server_Configuration/06_General#Scan_Tab

Second point: in many cases - both with MP 1.6 and 1.8 - it seems TV Server fails to lock on signal with the first tuner, and has to fall back to the second tuner. You can see this in the TV service log by searching for "lets try next available card". I'm not sure if that is because the feed to the first tuner is somehow different to than the second or... ? Just thought you should be aware of that.

Heat maybe deserves a fuller comment too...
The tuner seems to have been in use almost continuously from ~17:00 through to when the problems started. I'm not sure how big your case is or whether this is a "normal" usage situation for you. For myself: I know my satellite tuners would be pretty hot by that time. Especially in summer as I think it is in Germany at the moment (though not sure what the weather was like on that day at your house). Tuners can fail or misbehave in very hot conditions.
Satellite dish LNB LOFs can also drift with temperature change. LOF drift can cause random signal loss and lock issues.

Finally, I can't say that thee same problem wouldn't happen with MP 1.6. Due to the code freeze there has been exactly 2 changes in the TV library and TsWriter (ie. the components responsible for directly interacting with tuners) since MP 1.6 PR:
https://github.com/MediaPortal/MediaPortal-1/commit/ded8ede10aa5222a77772666fda0bdb73e138fa9
https://github.com/MediaPortal/MediaPortal-1/commit/31a60eaed85008741772ef3504610750c8fa5d94


Now some direct responses to your comments...

For me there definitely was no Update as I've started with "format c:"

An update is not required. Still hoping to see event logs for this MySQL problem. The watchdog with option 3 should give them to you. Can't explain how they would have been cleared in the last set of logs.

I've tried to install 1.8 some times yesterday but not a single installation gives me any signal. As soon as I install 1.6 the signal is there and the server starts and runs stable as I know it... So it must have something changed between those 2 releases what causing this massive issues here.

Would be interested to see these logs also... and if you're willing, try to increase the tune timeout setting mentioned above with 1.8 to see if it makes a difference.
The other thing that is obvious to me from the logs you've already provided is that the DVB EPG grabber was enabled for the 1.8 install, but not for the 1.6 install. That shouldn't make any difference. My point is that it appears like there are configuration differences, which could be enough to explain the problem without code differences.

And as I use the same MySQL version on both, the problem can't be related to MySQL. Even the not working Database from 1.8 Server is working without issues if I downgrade the installation to 1.6.

MySQL is not the cause of the "no signal" problem, but it could be the cause of the no-auto-start problem. As above: need event logs showing a failed start to try and diagnose this... or you could look in the MySQL error log and see what is there.

Maybe it's not the server but the TV Client, I can't tell exactly. In my sleeping room I still have a 1.8 client and this also has no signal, no matter if I use 1.6 or 1.8 TV Server... But if it's the client why there is "No Signal" trying to manually start timeshifting inside the 1.8 TV Server config too??? Will change this client back to 1.6 also as soon as possible...

As you hopefully know, we don't claim that mixed client and server versions will work. Sometimes they do; sometimes they don't. At least the client can't change the tune result from the server, and the tune results in the 1.8 log files you already provided are clearly "no signal". Without logs from that client I can't say more.

But it's definitely no fault of Windows...

Agree. I don't think anybody is blaming Windows. I did say Windows won't start a service if the dependencies can't be started... but then it is the fault of the dependency for failing to start.

Hardware

I wouldn't say that the hardware is blameless yet. Good hardware doesn't just stop streaming while timeshifting.

MySQL

MySQL is not causing the no signal issue, but it could be responsible for the failure to auto-start the TV service.

Something must have changed in TV part of MP1.

As above: your configuration for MP 1.6 and 1.8 seems to be different. It doesn't have to be a code change.

Version 1.7 I never tried and I don't have it available here. If this is downloadable somewhere I can try 1.7 too, if this may help.

http://sourceforge.net/projects/mediaportal/files/MediaPortal Setup/MediaPortal 1.7.0/

In general I can't experiment too much with TV part as I only have this for LiveTV. No Setop Box, no other PC capable of receiving LiveTV,... I need to get the system up and running normally as soon as possible. And if I only can achieve this with MP 1.6 TV Server I will use it until eternity..

Understood.

Sometimes between saturday evening and sunday noon the path to Recording and Timeshift folders are changed back to C: Definitely without any interaction from me.

New database would do that, or possibly loss of access to the original locations (ie. share or RAM disk not available).

mm

 

[Lehmden]

Hi.

your configuration for MP 1.6 and 1.8 seems to be different.

Maybe as I did not configure 1.6 installation just want to watch TV at this time. But in meantime I have set up the configuration the same as in 1.8. I simply can not understand why 1.6 is working on exactly the same conditions and 1.8 is not, if there are no differences...
I'm not sure if I can do some more tries with 1.8 especially as this is a single seat installation and all my client settings are lost when I need to install 1.8 from scratch... If I find the time, I can do it, but no promises.

possibly loss of access to the original locations

RAM disk probably could be for some seconds (don't believe this but can not swear), but the Recording folder is set to a fixed local drive (D and this one definitely was available...

we don't claim that mixed client and server versions will work

I know and I didn't expect this to work. It was just to give all information I'm aware of.

I'd be interested to know if you've ever seen such a thing happen before

Never.

or if it happens again.

Every single time I've tried 1.8 on Monday. Changing to 1.6 with fresh DB-> working, changing to 1.8 with fresh DB->broken, changing to 1.6 with DB from broken 1.8 ->working,..