ok then, we need scannin logs from WinTV and from MP - maybe then we can figure out how WinTV detects them...
1.3.0 Final and Digital Channel Scans (2 Viewers)
- Thread starter breese
- Start date
- Thread starter
- #22
I have worked for hours on gathering info I think might help.
The last set of MP logs I uploaded are current. I have done nothing else on the server or client.
Included in the WinTV zip are all the log files I could find, the database files, some XML files it seems to be using, and because I updated to the newest version of WinTV, I included some of the ini files.
Also, the WinTV application scanned the entire cable and found 362 channels in 6 minutes. Way faster than MP.
Also in here is a spreadsheet I have been working on.
The top half I started has the WOW channels listing and the WinTV findings to all unencrypted QAM Channels. I was going to do a search of the MP scan files and add them to the spreadsheet but soon discovered a number of channels in MP are off by 1. I am sure you will see it....
The bottom half of the spreadsheet (Yellow seperator) is the Raw finding within the WinTV application.
Becuse I could not locate what I think would have been a simular MP scan log, I typed each and every one in and included Y if it found it to be encrypted and all the Channel names.
Needless to say, I have done everything I can think of to get as much info into your hands as possible.
Want more... tell me where it is and I will get it for you OR someone IM me and I will look into them having direct access.
More:
As the day went on I continued to see things that others have mentioned or I did. Here is a set of notes I created today while working on all this other stuff
-------------------------------------------------------------------------------
I have spent a great deal of time comparing WinTV channel findings and MP Findings. I have read more threads on issues from Unknown xxx.yy and answers are almost always “preview and rename”
Encrypted Red Balloons not showing up, and LUN being set to 10000 for all channels.
In an effort to help find the issues, I have done everything from creating new Freq Scan Files to changing SDT/VCT settings from Default to 120 seconds, doing multiple rescan’s., and setting TVService to everything from Default to Realtime.
All the SDT/VCT has done is make the scans take a lot longer.
Multiple scans do find more channels (also as Unknown xxx.yy) but doing this also makes it take longer for a completely ready system.
My latest effort is the creation of a spreadsheet broken down by my cable providers Channel Info, WinTV’s discovery of QAM (and other open) channels, and reading the Scan Log of MP’s scanning for channels using multiple different Freq Scan files.
Here is my current list of known issues… yes, some repeat info from earlier posts but just thought it might help someone who discovers this thread and wants up to date info without having to read the whole thread.
Channel scans produce an Unknown xxxx.yyy that is not human readable for end users.
In the US QAM world, channels are Channel.SubChannel (xx.yy) that are also usable for changing channels on a QAM ready TV.
Channel scans are not distinguishing encrypted channels (this one seems to come and go over time and MP updates).
Channel scans set LUN to 10000 for all channels found
As I said before, not dependent on General / Scan / SDT/VCT setting. Have tried everything from Default Seconds to 120 Seconds. Have also tried TVService priority from Default to Realtime.
LCN Issues have been raised multiple times going back to 2008 and as recent as 2012
https://forum.team-mediaportal.com/threads/one-mux-only-gives-me-10000-for-lcn.39647/
http://mantis.team-mediaportal.com/view.php?id=1367
https://forum.team-mediaportal.com/threads/scanning-satellite-19-2-is-naming-the-channels-10000-only.117301/
The last set of MP logs I uploaded are current. I have done nothing else on the server or client.
Included in the WinTV zip are all the log files I could find, the database files, some XML files it seems to be using, and because I updated to the newest version of WinTV, I included some of the ini files.
Also, the WinTV application scanned the entire cable and found 362 channels in 6 minutes. Way faster than MP.
Also in here is a spreadsheet I have been working on.
The top half I started has the WOW channels listing and the WinTV findings to all unencrypted QAM Channels. I was going to do a search of the MP scan files and add them to the spreadsheet but soon discovered a number of channels in MP are off by 1. I am sure you will see it....
The bottom half of the spreadsheet (Yellow seperator) is the Raw finding within the WinTV application.
Becuse I could not locate what I think would have been a simular MP scan log, I typed each and every one in and included Y if it found it to be encrypted and all the Channel names.
Needless to say, I have done everything I can think of to get as much info into your hands as possible.
Want more... tell me where it is and I will get it for you OR someone IM me and I will look into them having direct access.
More:
As the day went on I continued to see things that others have mentioned or I did. Here is a set of notes I created today while working on all this other stuff
-------------------------------------------------------------------------------
I have spent a great deal of time comparing WinTV channel findings and MP Findings. I have read more threads on issues from Unknown xxx.yy and answers are almost always “preview and rename”
Encrypted Red Balloons not showing up, and LUN being set to 10000 for all channels.
In an effort to help find the issues, I have done everything from creating new Freq Scan Files to changing SDT/VCT settings from Default to 120 seconds, doing multiple rescan’s., and setting TVService to everything from Default to Realtime.
All the SDT/VCT has done is make the scans take a lot longer.
Multiple scans do find more channels (also as Unknown xxx.yy) but doing this also makes it take longer for a completely ready system.
My latest effort is the creation of a spreadsheet broken down by my cable providers Channel Info, WinTV’s discovery of QAM (and other open) channels, and reading the Scan Log of MP’s scanning for channels using multiple different Freq Scan files.
Here is my current list of known issues… yes, some repeat info from earlier posts but just thought it might help someone who discovers this thread and wants up to date info without having to read the whole thread.
Channel scans produce an Unknown xxxx.yyy that is not human readable for end users.
In the US QAM world, channels are Channel.SubChannel (xx.yy) that are also usable for changing channels on a QAM ready TV.
Channel scans are not distinguishing encrypted channels (this one seems to come and go over time and MP updates).
Channel scans set LUN to 10000 for all channels found
As I said before, not dependent on General / Scan / SDT/VCT setting. Have tried everything from Default Seconds to 120 Seconds. Have also tried TVService priority from Default to Realtime.
LCN Issues have been raised multiple times going back to 2008 and as recent as 2012
https://forum.team-mediaportal.com/threads/one-mux-only-gives-me-10000-for-lcn.39647/
http://mantis.team-mediaportal.com/view.php?id=1367
https://forum.team-mediaportal.com/threads/scanning-satellite-19-2-is-naming-the-channels-10000-only.117301/
Last edited:
- September 1, 2008
- 21,577
- 8,224
- Home Country
-
New Zealand
You're basically right Vasilich
There are currently limitations on TV Server's ability to determine whether a channel is encrypted or not.
This applies to all transmission standards based on MPEG 2.
In other words, DVB-S, DVB-S2, DVB-T... etc. etc.
It applies to both ATSC OTA and ATSC/SCTE cable in North America.
I suspect @breese hasn't noticed it with ATSC previously because I don't think there are any encrypted OTA transmissions in the US.
My SF Bay area has 1 Physical Channel that has 3 normal ATSC subchannels and 4 or 5 encrypted as part of a OTA paid service called Airbox.com. The encrypted channels show up as red/locked, the clear ATSC channels show up as green/unlocked. For OTA scanning this does not seem to cause problems, but I do see some channels that show "Unknown" for the channel names. Most of the time if I delete the "unknown" channels, do a rescan, the scanning works the 2nd time. This is for OTA, I don't have cable/QAM so I don't have any experience with that option.
I was surprised the 1st time I saw encrypted channels. In the SF area this is KKPX-TV (65), see http://www.rabbitears.info/market.php and click on San Francisco and KKPX (65). I've never seen anything about airbox.com on local area news or where you could buy the "airbox" to receive these channels. In MePo I tried flipping the "Free To Air" bit but I still was not able to watch those channels so I guess they are really encrypted. With a "normal TV" the channel scan does not detect any of the encrypted/airbox channels.
I was surprised the 1st time I saw encrypted channels. In the SF area this is KKPX-TV (65), see http://www.rabbitears.info/market.php and click on San Francisco and KKPX (65). I've never seen anything about airbox.com on local area news or where you could buy the "airbox" to receive these channels. In MePo I tried flipping the "Free To Air" bit but I still was not able to watch those channels so I guess they are really encrypted. With a "normal TV" the channel scan does not detect any of the encrypted/airbox channels.
- Thread starter
- #25
Same card... Swapped from Digital Cable to OTA Digital Antenna
One thing I did just notice... With OTA the Signal Level actually works where when using Digital Cable it never shows anything... Both Cable and OTA do register Signal Quality....
Here are my OTA channels and yes... there are encrypted ones
One more thing... Everything that has a Name Attacted to it is Without EPG, or any plugins...
Even turned off Schedule Direct... So the QAM info is raw info
One thing I did just notice... With OTA the Signal Level actually works where when using Digital Cable it never shows anything... Both Cable and OTA do register Signal Quality....
Here are my OTA channels and yes... there are encrypted ones
One more thing... Everything that has a Name Attacted to it is Without EPG, or any plugins...
Even turned off Schedule Direct... So the QAM info is raw info
Last edited:
breese,
not sure if this will help, but the HDHR (silcondust) webpage has info on OTA (digital antenna) and QAM channel scans for many zipcodes. If you click on the following link, enter your zipcode, you can see OTA channels. If you click on provider in upper left side of webpage, you can change the provider for a cable option. With zip 60056 I see some options for WideOpenWest, not sure of your real zipcode or if this info will help.
http://www.silicondust.com/support/channels/
for zip 60056
http://www.silicondust.com/hdhomerun/lineup_web/US:60056#lineup_9571020
not sure if this will help, but the HDHR (silcondust) webpage has info on OTA (digital antenna) and QAM channel scans for many zipcodes. If you click on the following link, enter your zipcode, you can see OTA channels. If you click on provider in upper left side of webpage, you can change the provider for a cable option. With zip 60056 I see some options for WideOpenWest, not sure of your real zipcode or if this info will help.
http://www.silicondust.com/support/channels/
for zip 60056
http://www.silicondust.com/hdhomerun/lineup_web/US:60056#lineup_9571020
- Thread starter
- #27
Yep... Thanks... I was just making a point that without any assistance, the OTA QAM scans
1 - See the QAM info for most of the info with No assistance
2 - There are Encripted channels for OTA here in my area
I am not saying the Chicago area because my Antenna can, has, and will see Millwaukee WI
So, there is somethng a miss with MP scanning a real Digital Cable System that is QAM frendly (to a point).
There is also an issue with the cable provider and I am dealing with that but as always.. they are slow to respond.
Between having to do multiple scans in MP to find all the channels, LCN(?) always being 10000 and other stuff I have been listing in this thread, maybe someone will ask the right question that will help MP find the issues...
1 - See the QAM info for most of the info with No assistance
2 - There are Encripted channels for OTA here in my area
I am not saying the Chicago area because my Antenna can, has, and will see Millwaukee WI
So, there is somethng a miss with MP scanning a real Digital Cable System that is QAM frendly (to a point).
There is also an issue with the cable provider and I am dealing with that but as always.. they are slow to respond.
Between having to do multiple scans in MP to find all the channels, LCN(?) always being 10000 and other stuff I have been listing in this thread, maybe someone will ask the right question that will help MP find the issues...
the MePo v1.3.0 LCN Channels = 10000 is actually an improvement but a bit annoying. At least now you can modify the Channel number to use any number you want but you must use all digits. I use a Windows Media Center like 4-digit convention since you cannot use a "-" or "." in the channel number. 1021 = 2-1, 1091 = 9-1, 1092 = 9-2. 1441 = 44-1, etc. Its takes a bit of time to set the channels, but you can get them to display in the EPG and use a remote. You can also just number the channels 1 to N in any order you want. Most of the time I use the EPG or mini-EPG to select/change the channel and rarely use channel numbers.
- Thread starter
- #29
If anyone managed to look at the spreadsheet I included, you would see that WinTV clearly see's encrypted channels but MP scanning the same Digital Cable does not... No Red Bubbles. You have test the channels to find them.
- September 1, 2008
- 21,577
- 8,224
- Home Country
-
New Zealand
Hello again breese
As I said to you previously, I think there are quite severe limitations on what we can do to solve or even improve most of the points you've raised. I've made comments on each one below.
I know this is a long post, but please read carefully. I feel like I'm starting to repeat the same things @hello_joe already explained to you... and that is a little frustrating. I'd remind you that many cable providers hate clear QAM, and they do their utmost to make it really difficult to use anything other than their set-top-box. They are overjoyed that clear QAM is going away:
http://www.engadget.com/2012/10/14/fcc-to-allow-encryption-of-basic-cable-with-a-few-strings-that/
Here we go...
-----------------------------------------------------------------------------------------
Yes, preview and rename is the standard response.
Having access to a lineup listing with "QAM channel numbers" puts you in a privileged minority.
Really, most other people have no choice but to use preview and rename.
As far as I know, this applies in every other piece of HTPC software that supports clear QAM, except maybe WMC... because they pay for channel and EPG info. MythTV, N-PVR, WinTV... we're all in the same boat.
SUMMARY: WE CAN CHANGE THE NAMING CONVENTION OF UNKNOWN CHANNELS
-----------------------------------------------------------------------------------------
This is a known issue that doesn't only apply to cable TV. For discussion:
https://forum.team-mediaportal.com/threads/wrong-detection-of-fta-disables-watching-channel.109326/
We will find a way to fix this eventually, but it is non-trivial.
SUMMARY: LONG STANDING ISSUE, VERY DIFFICULT TO FIX
-----------------------------------------------------------------------------------------
This is a really complex topic. I'll do my best to try and keep the explanation simple.
First, I don't know what "LUN" stands for, but in the rest of the world we call that field an LCN (= logical channel number).
We use it to change channels (zap) with our remotes.
In North America my understanding is that most people would call it a "virtual channel" (VCN).
The standard for transmitting LCN/LUN/VCN data depends on location. Briefly...
In North America, ATSC and SCTE standards (ANSI SCTE 65 and ATSC A-65) define one-part (eg. xxx) and two-part (eg. xx.yy) VCNs. For OTA ATSC and SCTE cable, we support retrieving the two-part channel number from the L-VCT (virtual channel table - PSIP). When available, you'll see these numbers in the "major channel" and "minor channel" fields.
In the world outside North America DVB is the most widely used broadcast standard. DVB does not specify a standard way of transmitting LCNs, so many broadcasters use proprietary methods. Having said that, there is a de-facto standard from Nordig (which we support).
(Note: all the links that you gave reference DVB related issues, so they are irrelevant for your situation.)
Lets compare and contrast OTA ATSC and cable...
By FCC regulation, OTA broadcasters must transmit PSIP. PSIP includes the L-VCT. Hence you should expect to receive channel names and numbers in this scenario.
In complete contrast, cable TV has no such regulation. In fact, SCTE 65 specifies that channel names and VCNs should be carried in an out of band signal. Receiving that signal requires a QPSK tuner. Clear QAM tuners physically cannot demodulate QPSK by nature of the fact that they are QAM tuners, so there is absolutely no way that you can receive this data with your current tuner. Impossible, period.
Now here is where it gets complicated. There is a bit of an exception to the cable rule...
As you know, you have names and VCNs (major/minor channel) for a handful of your channels like ABCHD. Why?
Well, my understanding is that there is some kind of regulation that requires cable providers to transmit ATSC PSIP in very specific scenarios related to local channels and clear QAM. However if I recall correctly, the regulation only applies if the ATSC broadcaster supplies the required info to the cable provider. As such, it is sometimes possible to receive limited information about some clear QAM channels. MP does its best to receive and show this info.
SUMMARY: EXCEPT IN EXCEPTIONAL CIRCUMSTANCES IT IS LITERALLY IMPOSSIBLE TO RECEIVE CHANNEL NAMES AND LCN/VCN/LUNs WITH A CLEAR QAM TUNER. YOU MUST MANUALLY SET THESE NUMBERS IF YOU DON'T HAVE A CABLECARD TUNER
-----------------------------------------------------------------------------------------
Changing the TVService priority is not a relevant or useful way to deal with this problem.
Increasing the SDT/VCT timeout only makes sense if the information that you're hoping to receive (ie. channel names and "LUNs") are actually available in the broadcast stream. In the case of your cable provider, they're clearly not available (independently confirmed with WinTV), ergo increasing the timeout is pointless.
SUMMARY: INCREASING THE VCT TIMEOUT IS A VALID WAY TO TROUBLESHOOT ISSUES WITH MISSING CHANNEL NAMES, HOWEVER IT IS NOT A SILVER BULLET - IF THE INFORMATION IS NOT AVAILABLE, THEN IT IS POINTLESS
-----------------------------------------------------------------------------------------
SUMMARY: (MORE INFO REQUIRED)
-----------------------------------------------------------------------------------------
The cable TV standards that I've read don't mention anything about a "QAM channel number". The closest thing I've seen would be the ATSC two-part channel number... but at this point I'm not convinced they're the same thing. So I'm not sure if that is specific to WOW... in which case I question whether it would be a good thing for us to support.
SUMMARY: IT WOULD BE POSSIBLE TO ADD SUPPORT FOR ZAPPING WITH XX.YY LCNS, HOWEVER THE EFFORT REQUIRED TO SUPPORT THIS IS NOT INSIGNIFICANT
mm
Once again a sincere thanks for the time you're putting in.
As I said to you previously, I think there are quite severe limitations on what we can do to solve or even improve most of the points you've raised. I've made comments on each one below.
I know this is a long post, but please read carefully. I feel like I'm starting to repeat the same things @hello_joe already explained to you... and that is a little frustrating. I'd remind you that many cable providers hate clear QAM, and they do their utmost to make it really difficult to use anything other than their set-top-box. They are overjoyed that clear QAM is going away:
http://www.engadget.com/2012/10/14/fcc-to-allow-encryption-of-basic-cable-with-a-few-strings-that/
Here we go...
-----------------------------------------------------------------------------------------
Yes, preview and rename is the standard response.
Having access to a lineup listing with "QAM channel numbers" puts you in a privileged minority.
Really, most other people have no choice but to use preview and rename.
As far as I know, this applies in every other piece of HTPC software that supports clear QAM, except maybe WMC... because they pay for channel and EPG info. MythTV, N-PVR, WinTV... we're all in the same boat.
SUMMARY: WE CAN CHANGE THE NAMING CONVENTION OF UNKNOWN CHANNELS
-----------------------------------------------------------------------------------------
This is a known issue that doesn't only apply to cable TV. For discussion:
https://forum.team-mediaportal.com/threads/wrong-detection-of-fta-disables-watching-channel.109326/
We will find a way to fix this eventually, but it is non-trivial.
SUMMARY: LONG STANDING ISSUE, VERY DIFFICULT TO FIX
-----------------------------------------------------------------------------------------
This is a really complex topic. I'll do my best to try and keep the explanation simple.
First, I don't know what "LUN" stands for, but in the rest of the world we call that field an LCN (= logical channel number).
We use it to change channels (zap) with our remotes.
In North America my understanding is that most people would call it a "virtual channel" (VCN).
The standard for transmitting LCN/LUN/VCN data depends on location. Briefly...
In North America, ATSC and SCTE standards (ANSI SCTE 65 and ATSC A-65) define one-part (eg. xxx) and two-part (eg. xx.yy) VCNs. For OTA ATSC and SCTE cable, we support retrieving the two-part channel number from the L-VCT (virtual channel table - PSIP). When available, you'll see these numbers in the "major channel" and "minor channel" fields.
In the world outside North America DVB is the most widely used broadcast standard. DVB does not specify a standard way of transmitting LCNs, so many broadcasters use proprietary methods. Having said that, there is a de-facto standard from Nordig (which we support).
(Note: all the links that you gave reference DVB related issues, so they are irrelevant for your situation.)
Lets compare and contrast OTA ATSC and cable...
By FCC regulation, OTA broadcasters must transmit PSIP. PSIP includes the L-VCT. Hence you should expect to receive channel names and numbers in this scenario.
In complete contrast, cable TV has no such regulation. In fact, SCTE 65 specifies that channel names and VCNs should be carried in an out of band signal. Receiving that signal requires a QPSK tuner. Clear QAM tuners physically cannot demodulate QPSK by nature of the fact that they are QAM tuners, so there is absolutely no way that you can receive this data with your current tuner. Impossible, period.
Now here is where it gets complicated. There is a bit of an exception to the cable rule...
As you know, you have names and VCNs (major/minor channel) for a handful of your channels like ABCHD. Why?
Well, my understanding is that there is some kind of regulation that requires cable providers to transmit ATSC PSIP in very specific scenarios related to local channels and clear QAM. However if I recall correctly, the regulation only applies if the ATSC broadcaster supplies the required info to the cable provider. As such, it is sometimes possible to receive limited information about some clear QAM channels. MP does its best to receive and show this info.
SUMMARY: EXCEPT IN EXCEPTIONAL CIRCUMSTANCES IT IS LITERALLY IMPOSSIBLE TO RECEIVE CHANNEL NAMES AND LCN/VCN/LUNs WITH A CLEAR QAM TUNER. YOU MUST MANUALLY SET THESE NUMBERS IF YOU DON'T HAVE A CABLECARD TUNER
-----------------------------------------------------------------------------------------
Changing the TVService priority is not a relevant or useful way to deal with this problem.
Increasing the SDT/VCT timeout only makes sense if the information that you're hoping to receive (ie. channel names and "LUNs") are actually available in the broadcast stream. In the case of your cable provider, they're clearly not available (independently confirmed with WinTV), ergo increasing the timeout is pointless.
SUMMARY: INCREASING THE VCT TIMEOUT IS A VALID WAY TO TROUBLESHOOT ISSUES WITH MISSING CHANNEL NAMES, HOWEVER IT IS NOT A SILVER BULLET - IF THE INFORMATION IS NOT AVAILABLE, THEN IT IS POINTLESS
-----------------------------------------------------------------------------------------
This is something I'm not able to explain or investigate without specific examples and log files. More info required.
SUMMARY: (MORE INFO REQUIRED)
-----------------------------------------------------------------------------------------
MP does not support using xx.yy channel numbers for changing channels. This is something that could be added... however...
The cable TV standards that I've read don't mention anything about a "QAM channel number". The closest thing I've seen would be the ATSC two-part channel number... but at this point I'm not convinced they're the same thing. So I'm not sure if that is specific to WOW... in which case I question whether it would be a good thing for us to support.
SUMMARY: IT WOULD BE POSSIBLE TO ADD SUPPORT FOR ZAPPING WITH XX.YY LCNS, HOWEVER THE EFFORT REQUIRED TO SUPPORT THIS IS NOT INSIGNIFICANT
mm