[mythtv] DVB alpha-0.4

[Mike Wilcox]

Hi,

Kenneth Aafloy wrote:

>http://home.no/mythbox/dvb-alpha-0.4.tar.bz2
>
>Thanks to everyone that have contributed by reporting errs and such.
>

I'm new to getting my DVB-T card working with Mythtv (though I've 
tinkered with analogue cards in the past), so the above is the first 
code I've used to try getting a picture.

I seem to have hit a problem that, if I understand correctly, has the 
same symptoms of a wrong "use_ts" setting - I get zero-length 
recordings, and if I try to watch live tv, I get a blank screen (and the 
front end hangs). However, setting different values of "use_ts" has no 
effect. Further experimentation suggests something to do with the 
threading mutex's instead. Read on...

Just to be sure this is all correct, I am using:
  o Athlon 1800+ on an Nforce2 m/b with onboard Geforce 4 MX chipset.
  o Hauppauge/Technotrend DVB-T budget card with Philips TDA10045H 
frontend. No decryption hardware.
  o Redhat 9, with the 2.4.20-20.9 kernel
  o gcc 3.2.2-5
  o Mythtv from CVS, with dvb-alpha4 patch
  o the 1.0.0 dvb device driver.
  o a tzap channel config for the Crystal Palace transmitter.
  o an XMLTV config created manually
  o a fresh mysql database, with only this card configured
  o channels configured using the mythfilldatabase program
  o a manual setup of the dvb_channel table, using hints from the 
mailing list & code to determine what values to store.

I have general reception working, using things like
  $ tzap -r "BBC ONE"
  $ xine -V xv stdin://mpeg2 < /dev/dvb/adapter0/dvr0

When I start up the backend, I get the following output:

    Starting up as the master server.
    DVB#0 Using DVB card 0, with frontend Philips TDA10045H.
    DVB#0 Trying to tune to channel 1.
    DVB#0 Frequency: 505833330.
    DVB#0 Waiting for frontend event after tune.
    DVB#0 Poll timed out waiting for frontend device, retrying.
    <snip between 4 and 10 more of these...>
    DVB#0 Status: CARRIER | VITERBI | SIGNAL | SYNC | LOCK.
    2003-09-05 19:55:07 Enabled verbose msgs : important general
    2003-09-05 19:55:09 Found changes in the todo list.

When I configure a recording in the frontend, the backend shows the 
following (and nothing more):

    2003-09-05 19:59:31 Started recording "five" on channel: 1004 on
    cardid: 1, sourceid 1
    DVB#0 Trying to tune to channel 5.
    DVB#0 Frequency: 561833330.
    DVB#0 Waiting for frontend event after tune.
    DVB#0 Status: NO LOCK!
    DVB#0 Poll timed out waiting for frontend device, retrying.
    DVB#0 Poll timed out waiting for frontend device, retrying.
    DVB#0 Poll timed out waiting for frontend device, retrying.
    DVB#0 Status: CARRIER | VITERBI | SIGNAL | SYNC | LOCK.
    Changing from None to RecordingOnly
    DVB#0 Card opened successfully.
    DVB#0 Unable to create Link Layer interface with CAM, do your card
    support it?
    DVB#0 DVBCam ended

I decided to add some debugging into dvbrecorder.cpp to see what was 
happening with the PIDs and the use_ts parameter (I didn't trust that 
I'd set these correctly, and the debates on the mailing list left me a 
little, er, bemused.

A long story short... It seems that nothing was being set up for the 
PIDs, and nothing was happening with the use_ts parameter. It finally 
transpired that things were locking at the "pthread_mutex_lock()" call. 
With the following patch in place, commenting out the mutex, I finally 
get to see recordings & live tv!

    if (dvbchannel)
    {
++      ERR("dvbchannel: true");
        if (sections)
            sections->ChannelChanged(dvbchannel);
        if (cam)
            cam->ChannelChanged(dvbchannel);
    }
++  ERR("locking channel");
--  pthread_mutex_lock(&dvbchannel->lock);
++  //pthread_mutex_lock(&dvbchannel->lock);
++  ERR("setting pids");
    SetDemuxFilters(dvbchannel->pids);
++  ERR("unlocking channel");
--  pthread_mutex_unlock(&dvbchannel->lock);
++  //pthread_mutex_unlock(&dvbchannel->lock);
    channel_changed = false;

With this patch in place, the backend logs continue with:

    DVB#0 channel_changed: true
    DVB#0 dvbchannel: true
    DVB#0 locking channel
    DVB#0 setting pids
    DVB#0 Setting pids: Audio( 6018 ) Video( 6017 )
    DVB#0 Setting pids: Teletext( NONE ) Subtiltle( NONE )
    DVB#0 Setting pids: Pcr( NONE ) Other( NONE )
    DVB#0 unlocking channel
    Audiostream: Layer: 1  Bit rate: free  Freq: 0.0 kHz
    Videostream: ASPECT: 16:9  Size = 720x576  FRate: 25 fps  BRate:
    4.70 Mbit/s
    Changing from RecordingOnly to None

I know I can't really expect everything to continue working fully 
correctly after this kind of fiddling with thread protection, but all 
seems to work well with tuning, recording, and watching live TV.

I can't see anything else that's trying to do a mutex on 
dvbchannel->lock, but then I can't see where dvbchannel-> lock is 
declared either. Is this mutex shared with other channels in some way? 
Anything I can do to track down where the lock is actually held?

Things aren't entirely perfect with viewing - I do get a variety of 
problems that seem to match other experiences...

    o some segv's after recording completes (not gdb enabled at the
    moment though).
    o failure to display correctly if a channel changes something about
    the stream while recording is taking place. I don't know exactly
    what, but I've seen it twice related to the start or end of the ITV
    news programmes (and still have one recorded).
    o occasional lockup on changing live-tv channels. particularly from
    a qam_64 channel to qam_16 channel.
    o occasional lockup when seeking forward or back in a recorded.

but I'm not so worried about these until I know the effect I'm having by 
losing the mutex.

I've also seen one backend log message that referred to "DVB #54", 
logging something related to CAM , when stopping a recording. Sorry - 
lost the details though!

Cheers,

   Mike