DVB: Problems tuning on myth server, but no problems tuning on mythbackend.

[homer_simpson_loves_u@…]

This applies from SVN 8390 through head. I haven't gotten something further back to work recently.

If I use any SVN version from 8390 to latest and run the frontend on the same machine as the backend, channel changes are broken and rarely work on channel changes between switch inputs.

I assumed it was a hardware problem and spent a great deal of time trying to get it to work.

I removed one Nexus DVB card and the other one still failed. I swapped to the first card running alone with the same results. Although with only one card it seemed more reliable, it still was not 100%.

I hacked around in the switch routines in the kernel with no noticable improvement.

I played with different PCI slots, adjusted bios settings, stopped overclocking. I did everything except swap motherboards, which is too much of a pita to even attempt with my time budget.

Nothing I did made it reliable. I began to feel that my several months of stability were a figment of my imagination...

Then, after giving up, I decided to watch some TV and ran mythfrontend on my laptop...

And it worked perfectly. On my laptop every channel change locks and video is displayed. No matter how many channel changes or different switch or card inputs I choose. It works flawlessly.

So I think I thought I was stable because I was testing using the front end on my laptop.

I'm convinced its a timing problem. My laptop is connected via wireless. So there is a huge lag between tcp packets traveling from it to the myth server.

So today I sat down and generated front end (-v channel) and back end (-v channel, record) logs.

Looking through I can see on the fe/be same machine log a failed lock and I can see a lock to the wrong PAT on two channel changes.

The failed log actually shows serveral failures. I did not have -v siparser.

I have no idea how to track down this problem. I don't know enough about the code to know what to look for.

Daniel, I'm hoping that you'll have time after .19 is released to walk me through the steps necessary to debug this.

I've attached four sample logs. Please note that when the frontend was running on my laptop, it crashed for some other reason and that's why there aren't as many channel changes.

Also note the logs are from running 8390. The problem is identical at the head.

Homer

[Homer]

Frontend and Backend logs from channel changes.

[danielk]

Homer, remind me of this after I get the Legacy switch patch integrated. The problem is that we are reporting a signal lock, but we haven't moved the rotor yet. (Or you have broken DVB drivers that just report tuning success without actually doing the tuning.)

You can make this work by adding a sleep() call in dvbchannel.cpp:wait_for_backend, start with 60 seconds and decrease it until it doesn't work anymore for your longest tuning change.

[Homer]

I added a sleep to the top of wait_for_backend. I started with a second and worked my way up.

With a 10 second pause, it did not tune correctly often, when changing between switch inputs.

I couldn't get 60 seconds to work at all, the frontend exited with "problems displaying video" error message and then went black. I had to ctrl-c it to kill it.

If a ten second pause doesn't help it, I don't think a 60 second pause will help it. When the frontend is on a different machine, it changes channels in less than two seconds, and it works every time.

If you think of any other ways to track this, just let me know.

Thanks,

Homer

[Homer]

Its working!

I applied this patch (a suggestion you made on another bug report) and built 8789.

And, although it takes a couple of channel changes to get synched, once I get lock on two inputs I can bounce back and forth and get a lock every time.

Don't have time to determine the min-value, I'll try to do that tomorrow.

I'm not positive this patch fixed it, because if I remember correctly you checked in at least one other fix that could be what fixed it.

I'll try to determine that tomorrow by undoing this change and seeing if the problem returns.

Thanks much Daniel.

Homer

--- ../original/mythtv.8751/libs/libmythtv/RingBuffer.h 2006-01-28 14:00:06.0000
00000 -0800
+++ libs/libmythtv/RingBuffer.h 2006-01-30 13:09:29.000000000 -0800
@@ -42,7 +42,7 @@
     bool      IsOpen(void)           const;

     // General Commands
-    void OpenFile(const QString &lfilename, uint retryCount = 4);
+    void OpenFile(const QString &lfilename, uint retryCount = 15);
     int  Read(void *buf, int count);
     void Reset(bool full = false, bool toAdjust = false);

[Homer]

Apparently this problem is not fixed by the RingBuffer? Patch. I set it back to 4 and it still seems to be changing channels properly.

It must have been fixed by one of your other changes.

I'll try latest SVN and make sure I'm not halucinating.

Homer

[Homer]

I'm running 8806 and I've been able to break things by changing ringbuffer.h back to:

// General Commands 
void OpenFile(const QString &lfilename, uint retryCount = 4); 

So I'm not sure what I did wrong when I reversed the patch above...

I have just re-confirmed, changing this retryCount to 12 solves my "lock" problem.

Homer

[danielk]

The problem in this ticket is not well defined, it is probably a duplicate of one of the tuning tickets (#894, #1049, #1552).