mythtv doesn't record yet says it's all OK

[udovdh@…]

MythTV runs fine yet no mpeg files are recorded onto the harddisk. Yes, I (may have) configured something wrong. But there are no errors, warnings, etc. That alone is very bad. Next is of course restoring the functionality; that's at least as important.

21-fixes does this as does trunk. (!)

[udovdh@…]

Various system/mythtv info to help troubleshooting

[wombo1@…]

I think I might be having a similar problem but on average only on 20% recordings.

Sometimes when it records nothing gets written to disk. It appears in Mythweb but doesnt have a file size or image.

[udovdh@…]

Thanks for the comment; I also use mythweb for checking the status, bsedies the xterm of course. Maybe you can post similar system info like I did? Could one of the devs please explain what info might be missing?

mysql.txt: DBHostName=localhost DBHostPing=no DBUserName=mythtv DBPassword=mythtv DBName=mythconverg DBType=QMYSQL3 LocalHostName?=localhost

config.xml: <Configuration>

<UPnP>

<UDN>

<MediaRenderer?>e67ab8df-fcca-4411-8ce8-0c93bc17c59f</MediaRenderer?>

</UDN> <MythFrontend>

<DefaultBackend?>

<DBHostName>localhost</DBHostName> <DBUserName>mythtv</DBUserName> <DBPassword>mythtv</DBPassword> <DBName>mythconverg</DBName> <DBPort>0</DBPort>

</DefaultBackend?>

</MythFrontend>

</UPnP>

</Configuration>

[manwe <nettibug@…>]

I have the same problem. Hard do diagnose and affects only a small number of recordings. At least version r17046 (in trunk) has this problem. Maybe ticket #5140 is a fix for this (it checks if file got opened or not).
I'm going to try it out.

• Manwe

[udovdh@…]

Thanks for the tip about hte patch. I stopped the backend, rebuilt mythtv after applying the patch and copied libmythtv in place. After a start of the backend I see no errors being logged because of this patch (I have important in the -v options). I DO think though that the patch from #5140 is a good idea and this way of error checking should be applied genereously and generally.

[manwe]

Replying to manwe:

I have the same problem. Hard do diagnose and affects only a small number of recordings. At least version r17046 (in trunk) has this problem. Maybe ticket #5140 is a fix for this (it checks if file got opened or not).
I'm going to try it out.

• Manwe

No help from #5140
-Manwe

[wombo1@…]

I dont have any data to back this up but the one constant I have observed is that it only happened on one of my tuners which is a very old visionplus. The new dvico USB tuner has not had a problem.

Could the tuner be losing lock or something?

[Manwe]

Replying to wombo1:

I dont have any data to back this up but the one constant I have observed is that it only happened on one of my tuners which is a very old visionplus. The new dvico USB tuner has not had a problem.

Could the tuner be losing lock or something?

I'm trying to narrow done where the problem actually is, but for that I require one missed recording at that happens less than once a week.

[Manwe]

I'v come to the conclusion that either changing tuner settings to "wait for start sequence" or adding more delay on card tuning removed this problem for me. As of that test all recordings have started as they should have. (Could not pin point code section that is responsible for recording..)

[wombo1@…]

I have noticed in the last couple of days that if I have my TV turned on they never fail. So the TV could possibly be boosting the signal as the myth tuners and the TV are all on a crappy splitter.

I will try what you have suggested

[wombo1@…]

Yeah I have figured it out for me, it is todo with the TV being turned on as per the results below.

TV TURNED ON

cycle: 1 d_time: 0.001 s Sig: 40900 SNR: 0 BER: 481808 UBLK: 4843 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 2 d_time: 0.011 s Sig: 40893 SNR: 0 BER: 481808 UBLK: 4891 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 3 d_time: 0.008 s Sig: 40898 SNR: 0 BER: 481808 UBLK: 4981 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 4 d_time: 0.007 s Sig: 40894 SNR: 0 BER: 481808 UBLK: 5036 Stat: 0x1f [SIG CARR VIT SYNC LOCK ]

TV TURNED OFF

cycle: 1 d_time: 0.001 s Sig: 39818 SNR: 0 BER: 2097151 UBLK: 0 Stat: 0x1b [SIG CARR SYNC LOCK ] cycle: 2 d_time: 0.007 s Sig: 39818 SNR: 0 BER: 2097151 UBLK: 0 Stat: 0x1b [SIG CARR SYNC LOCK ] cycle: 3 d_time: 0.008 s Sig: 39827 SNR: 0 BER: 2097151 UBLK: 0 Stat: 0x1b [SIG CARR SYNC LOCK ] cycle: 4 d_time: 0.007 s Sig: 39821 SNR: 0 BER: 2097151 UBLK: 0 Stat: 0x1b [SIG CARR SYNC LOCK ]

In particular look at BER (Bit Error Rate) and UBLK

[udo]

For me this bug is s serious request for more error checking. How can a config be wrong (yes, it was all OK after reconfiguring the tuners, etc) yet nothing complains?

[sid.richards@…]

This happens to me every time if I am watching a pre-recorded show. I can not be watching a recording when a show is scheduled to start or no file gets created. If I'm not watching recordings when a recording is scheduled to start it works fine.

[sid.richards@…]

I found that I had two storage directories for that recording group and one was set to the root of the filesystem. When attempting to remove a directory it had got set to root. I could not remove the root directory so I pointed it to my video directory and removed the other entry. That fixed the problem.

[udo]

But you got no error, right? This means MythTV needs more error checking and reporting.

[stuartm]

Duplicate of #3872