"No Descrambler" on channels with no CCI encryption.

John Nevill · 2012-10-29T15:47:32+00:00

I have an hdhomerun prime with a Comcast m-card and HD subscription. I have compiled tvheadend 3.2 from source on my Ubuntu 12.04 x64 machine and I am using...

John Nevill

OK. So just to clarify, I ran dvbsnoop for 0x0036, which was sharing a frequency with two other channels. When I ran dvbtraffic it showed the bump at 0x0ea2 (video) and 0ea3, 0ea4 (audio for two languages). The other two bumps were video for the other channels sharing the frequency and also two minor bumps for audio for those two channels.

Can I assume then that the reason there are only, at most, like... 5 or 6 channels on a single frequency is because there are only so many PIDs? Also, if I'm understanding ATSC correctly, there is already a PID tied up the Program Map Table.

Villy Thomsen

Hi John,

Well, the rigth way to think about it to forget everything you know about analog TV. :-) Tuning to a frequency and that being = one channel/program, NOT true anymore.

In DVB-C/ATSC etc, you tune to a frequency. That frequency contains a MUX/multiplex of a number of programs/channels.

Each program consists of a couple of elementary Program ID's (PID's). As you've seen, one PID could be a video stream another audio stream, teletext, electronic program guide and so forth.

dvbtraffic lists the elementary PID's the MUX contains.

dvbsnoop -n1 0x00 lists the Program Associations Table (PAT), which basically lists all the programs the MUX contains. (and a "program" is just a collection of PID's).

A MUX is limited only by bandwidth. 0x2000 in dvbtraffic output list the combined bandwith of your mux, about 40 Mbit/sec in your case. The amount of PID's is only limited by that. So if you want HD channels on your MUX, and they each take 10 Mbit/sec, well you can only have 4. ;)

I have muxes here in DVB-C land with 12 to 13 channels which is probably around the max I'll guess (none of them being HD channels).

Jim Ancona

John,
I was reading up on PID's too. In addition to Villy's explanations, I found the Wikipedia article here
http://en.wikipedia.org/wiki/MPEG_transport_stream#PID
to be helpful.

John Nevill

Thanks Villy, that's very helpful! A frequency = mux. A mux has programs, and programs have PID's.

I see in tvheadend-land when I look at programs in each transport I see "streams", and these streams show the PID, Type (MPEG2VIDEO, AC3), position, and for the AC3 type streams, a language. All of which looks like what I saw in the dvbsnoops.

Would it be possible (and maybe this is a question for Adam) to change the PID in these files to the actual PID we've discovered? Or do you think that these virtual program maps may change?

Villy Thomsen

Anyway, for at little hack to try out if tvheadend can record your channels, try the following:

locate dvbhdhomerun/userhdhomerun/hdhomerun_tuner.cpp

find:

int ret = hdhomerun_device_set_tuner_filter(m_device, StrPidFilter.c_str());

Replace with:

int ret = hdhomerun_device_set_tuner_program(m_device, "1170");

Also find:

is << "auto:" <<freq; Replace with: is << "auto:" << 514000000; Obviously replace the frequency with one of yours combined with a program number being on that frequency. Program number you get from this output, or from dvbsnoop -n1 0x00, or from the hdhomerunconfig_gui (program number being thefirst number on a channel there):

Tuner 1 Status
Virtual Channel 176 TLC HD
Frequency 715.750 MHz

Program Number 15

715.750 MHz => 715750000.

For building:

sudo apt-get install cmake g++ (libraries/tools needed to compile the below)
cd $SRC/userhdhomerun

make

Steps to run:

# Stop tvheadend. Check with "ps aux | grep tvh" that it is not running.
# Stop dvbhdhomerun. "sudo service dvbhdhomerun-utils stop", "ps aux | grep userh" to check it is stopped.
# Run it. "sudo make run" from directory where you build and leave it in prompt.
# Start tvheadend again.
# Goto "DVR -> Recorder Schedule -> Add entry" and add a recording for your selected channel. Leave it for a couple minutes. Stop the record.
# Now, can you play back that recording in say VLC?

The above reproduces what the user phmt did in this link http://www.silicondust.com/forum/viewtopic.php?t=12653 where he was able to stream to a VLC player. The above just uses tvheadend to save the stream to disk instead using the same function calls.

Notice, tvheadend can get a little, eh, upset with the above hack, since every time it tunes to a different frequency it ends up the same place... Also, running hdhomerun_config_gui simultanous seems to crash userhdhomerun from time to time - so don't run that while testing the above.

Villy Thomsen

Oh, I should probably point out that the above is just a hack that forces one frequency and one program to constantly be set no matter what tvheadend does. So obviously only that channel can be recorded.

The final fix is a more complex thingy, the above is just proof of concept that we can get tvheadend to record a copy-freely channel from a HDHomerun Prime.

John Nevill

Alright. I'm dying to test this but in all my farting around I've hosed tvheadend... or something. I was unable to play any channel through tvheadend, so I cleared out the muxes and added my channels.conf back in for it to rescan. It found 6 channels instead of the hundreds it should have found. I have no idea what I did so you'll have to bear with me until I am able to get services/channels set back up again.

Jim Ancona

Hi Villy,

Sorry for the delay, but I finally got to test your experimental fix. It worked great. I was able to record and playback the hacked channel successfully.

Any idea how much effort it would be to turn this into a real fix?

Thanks again!

John Nevill

Thanks Jim! I've all but given up on tvheadend since making the terrible mistake of updating the firmware on my prime to the newest beta. At least, that's what I'm convinced broke the set up as tvheadend scans and scans and finds a hand full of services, where before it would find every last channel.

I need to stop pushing buttons.

Villy Thomsen

Hi Jim/John,

> Sorry for the delay, but I finally got to test your experimental fix. It worked great. I was able to record and playback the hacked channel successfully.
>

Good, proof of concept for that at least. :)

So for next hackish step, we need to get a mapping of PID<->Program, and then teach userhdhomerun to use that for tuning and see what happens. Fortunately there is already a tool that will scan everything and print out the mapping for us - so if one you could do the below and paste the output here - I'll see if I can teach userhdhomerun to use that.

Remember to stop tvheadend before doing this!
sudo apt-get install w-scan

sudo w_scan -f a -A 3 -c US > wscan_output.log

That will simply go scan through all frequencies and find what stuff there is, and output a line for each program. Long operation, takes half an hour for me here in DVB-C land. Info on w_scan here: http://linuxtv.org/wiki/index.php/W_scan you may want to tweek the -A parameter, read on that first.

Output in the file wscan_output.log is what we are interested in. For me I get something like this:

NatGeo HD;Stofa:610000:M256:C:6900:1540=27:1541=eng;1542:0:0:1154:1:31:0
BBC World News;Stofa:626000:M256:C:6900:1330=2:1331=eng:1339:0:1133:1:33:0
ZDF HD;Stofa:626000:M256:C:6900:2560=27:2561=deu;2562:2569:0:1256:1:33:0
Eurosport HD;Stofa:626000:M256:C:6900:2680=27:2681=dan:2689:0:1268:1:33:0

Eurosport 2 HD;Stofa:626000:M256:C:6900:2690=27:2691=dan,2692=eng:0:0:1269:1:33:0

Which contain both program number and PID's for video/audio/teletext in one convienient line per program.

> Any idea how much effort it would be to turn this into a real fix?
>

Very good question. To me it seems like no matter how it is done, it is going to be somewhat complex.

There is still some technical details/analysis I/we need to figure out. One thing that pops to mind is that right now in tvheadend (and any other linux dvb program), you can easily record more than one program on the same mux using only one tuner. You simply feed it with a filter contained the programs you want to record and that works magically. But PID filtering don't work for cablecard, here your explicitle need to ask a tuner to tune to a specific program - I haven't found in the API the possibility to record more than one program on one tuner/mux. So tvheadend expects to be able to record more than one program on a mux, and if that is not possible we need to fail that gracefully somehow.

Also there is the whole story of providing the PID<->program mapping before everything starts to work. That could/would work with the w_scan application - but is going to be difficult to explain to users. "Hey run this for a hour, then you can use tvheadend. Oh, and don't run tvheadend while you run, and remember to start it afterwards"... :)

Anyway, lets just try with output from w_scan, teach userhdhomerun to use that for mapping and see what happens. ;-)

Villy Thomsen

Oh, and John, the above is a good test for you also - if w_scan finds a lot more the tvheadend does, then tvheadend is of course the problem... ;-)

John Nevill

I had ran one of these earlier last week using "scan" on my first adapter and using my custom list of frequencies as reported from hdhomerun_config. You can check out the dump from that at http://pastebin.com/FMZJFEdY

It only grabbed names for the local channels, the remainder are just the hex values for the programs, which I was mapping manually to the found services in tvheadend (before it started crapping out on me). Just for reference AMC HD, which I was using in the dvbsnoops above is line:


[0014]:319750000:QAM_256:3746:3747:20

It shows the video and audio pids but doesn't show the actual program number (0x0036), just the virtual (0x0014).

I've tried to run w_scan a few different ways, but it just runs through 8vsb, finds nothing, then runs through qam256 on HRC's in like a second and reports back:

initial_tune:2167: Setting frontend failed QAM256 f=837000 kHz 843000: QAM256(time: 04:31) set_frontend:1761: ERROR: Setting frontend parameters failed (API v5.x) : 22 Invalid argument initial_tune:2167: Setting frontend failed QAM256 f=843000 kHz 849000: QAM256(time: 04:31) set_frontend:1761: ERROR: Setting frontend parameters failed (API v5.x) : 22 Invalid argument initial_tune:2167: Setting frontend failed QAM256 f=849000 kHz ERROR: Sorry - i couldn't get any working frequency/transponder Nothing to scan!!

As for my personal tvheadend/hdhomerun-beta problem, I am still able to run "scan" and it dumps fine, although on any program that it comes across where there isn't a name found (where it only reports the virtual hex) it says "WARNING: filter timeout pid 0x1fff"... although it writes the correct video pid and audio pid to the dump, so it may not mean much.

Let me know if I can push any more buttons to help make this happen.

Villy Thomsen

Hi John/Jim,

Hmmm, weird w_scan doesn't work for you.

Jim: can you try the same?

Scan and w_scan are quite different applications - w_scan provides a bit more information which is why it would be nice to be able to use that one.

John Nevill

well.. w_scan didn't work on my main server or my laptop... so I tried it on my web dev server in the basement that is running ubuntu 11.04 and it worked. http://paste.ubuntu.com/1334960/

I ran it using:

w_scan -f a -c US -A 2 -I us-IL-Waukegan -o 7 > scan_output.txt

where us-IL-Waukegan is my dvbscan formatted list of frequencies (which comprises every frequency for which I have programs).

I'll run it again using your parameters in case there was something important I was missing.

[UPDATE]
So.. no go on the parameters suggested. 8VSB returned no hits and the list of frequencies it runs automagically for the US return nothing. I believe using my us-IL-Waukegan list is the best way to go.

Jim Ancona

Sorry, I didn't get to trying w_scan yesterday, but I'll give it a try this evening.

Jim

John Nevill

On a seperate note, I believe I've figured out what they hosed in their latest firmware beta. Lucky me... My device only reports back 0x0000 as a tsid regardless of the frequency. I believe that tvheadend relies on the tsid (which I assume it calls a MUX ID) to do it's scanning, so only channels that are in the first scanned frequency are found.

Just Peachy. So yea... don't drop the beta on your device since you can't downgrade, the source is kept secret and it borks anything that relies on the tsid of a mux.

Jim Ancona

Villy,

I've been working on an alternate approach to doing the PID <-> Virtual Channel mapping in dvbhdhomerun. Basically, in HdhomerunTuner::StartStreaming, I call hdhomerun_device_get_tuner_streaminfo to get virtual channel information for the currently tuned frequency. For each program found, I select it using hdhomerun_device_set_tuner_program, then call hdhomerun_device_get_tuner_filter to get the PID filter that has been applied as a result of the set_tuner_program call. If it matches the PID passed to the StartStreaming call, then I have the correct program. If I can't find a program that matched the PID, I fall back to the original logic of setting the PID filter directly.

I've got this implemented, but I still have to test it. I'd be interested in any comments or suggestions you might have. In particular, do you see any reason why this can't work or is a really bad idea? If not that, then I'd appreciate anything you can tell me about how to test this.

Thanks!

Villy Thomsen

Hi Jim,

> I've been working on an alternate approach to doing the PID <-> Virtual Channel mapping in dvbhdhomerun. Basically, in HdhomerunTuner::StartStreaming, I call hdhomerun_device_get_tuner_streaminfo to get virtual channel information for the currently tuned frequency. For each program found, I select it using hdhomerun_device_set_tuner_program, then call hdhomerun_device_get_tuner_filter to get the PID filter that has been applied as a result of the set_tuner_program call. If it matches the PID passed to the StartStreaming call, then I have the correct program. If I can't find a program that matched the PID, I fall back to the original logic of setting the PID filter directly.
>

I did not know about the hdhomerun_device_get_tuner_streaminfo(), sounds like that'll make everything much easier.

> I've got this implemented, but I still have to test it. I'd be interested in any comments or suggestions you might have. In particular, do you see any reason why this can't work or is a really bad idea? If not that, then I'd appreciate anything you can tell me about how to test this.
>

Hmmm, to keep it simple just do the hdhomerun_device_get_tuner_streaminfo() + hdhomerun_device_set_tuner_program() for starters. get_tuner_filter() and checking wait with that.

One thing to keep in mind, is that StartStreaming() will be called a bunch of times when a program is tuned. One for each video/audio/teletext PID. That is just the way it is done in the linux kernel. But I don't see any harm in calling streaminfo() + set_tuner_program() each time it is hit.

Also keep in mind that set_tuner_program() only seems to work for one program per mux, so don't schedule two program on the same mux for starters - that'll screw things up. Otherwise, go go go! :-)

Villy Thomsen

Villy Thomsen wrote:
> Hi Jim,
>
> > I've been working on an alternate approach to doing the PID <-> Virtual Channel mapping in dvbhdhomerun. Basically, in HdhomerunTuner::StartStreaming, I call hdhomerun_device_get_tuner_streaminfo to get virtual channel information for the currently tuned frequency. For each program found, I select it using hdhomerun_device_set_tuner_program, then call hdhomerun_device_get_tuner_filter to get the PID filter that has been applied as a result of the set_tuner_program call. If it matches the PID passed to the StartStreaming call, then I have the correct program. If I can't find a program that matched the PID, I fall back to the original logic of setting the PID filter directly.
> >
> I did not know about the hdhomerun_device_get_tuner_streaminfo(), sounds like that'll make everything much easier.
>

Hmmm, no on closer inspection that doesn't look like it will work. get_tuner_streaminfo() returns all programs on the mux no matter what you have set for PID filtering (I think), but do try it anyway if I am wrong.

In any case I think you are on to something, there may be something else in the API that can gives us what we need. I don't have much time tonight (I'm in denmark btw, so there is some time difference) so do keep looking. ;)

Villy Thomsen

Villy Thomsen wrote:
> Villy Thomsen wrote:
> > Hi Jim,
> >
> > > I've been working on an alternate approach to doing the PID <-> Virtual Channel mapping in dvbhdhomerun. Basically, in HdhomerunTuner::StartStreaming, I call hdhomerun_device_get_tuner_streaminfo to get virtual channel information for the currently tuned frequency. For each program found, I select it using hdhomerun_device_set_tuner_program, then call hdhomerun_device_get_tuner_filter to get the PID filter that has been applied as a result of the set_tuner_program call. If it matches the PID passed to the StartStreaming call, then I have the correct program. If I can't find a program that matched the PID, I fall back to the original logic of setting the PID filter directly.
> > >
> > I did not know about the hdhomerun_device_get_tuner_streaminfo(), sounds like that'll make everything much easier.
> >
> Hmmm, no on closer inspection that doesn't look like it will work. get_tuner_streaminfo() returns all programs on the mux no matter what you have set for PID filtering (I think), but do try it anyway if I am wrong.
>

> In any case I think you are on to something, there may be something else in the API that can gives us what we need. I don't have much time tonight (I'm in denmark btw, so there is some time difference) so do keep looking. ;)

Seems like simply:

hdhomerun_device_get_tuner_program()

Is exactly what we need. So instead of get_tuner_streaminfo() just use that one. That gives exactly what program is tuned.

« Previous Page Next Page »