Sky UK/IT/AUS enhancements (4 Viewers)
- Thread starter miroslav22
- Start date
- Status
- September 1, 2008
- 21,577
- 8,224
- Home Country
-
New Zealand
I was thinking more along the lines of configuration issues, but that can be done too if you like. I also like your idea of PID filtering (which is kind of what TsWriter does with section decoders (SetPid() etc.), however there are some crinkles that I'm not sure whether you've thought about. For example, there is some hardware that has PID filters built in and the TV library (or grabber) has to be able to tell the hardware to clear the appropriate PIDs. Yes, some of this hardware is old, but the FloppyDTV is/was very poplular. The HDHomeRun and other newer network-attached-tuners also have PID filters to keep network bandwidth to a minimum.
The other issues that I was thinking of are mostly configuration related. For example, consider the following real-world problem.
Sky NZ has HD and SD versions of a bunch of channels. HD versions are available to those who pay for the "HD ticket"; those who don't pay get the SD versions. Possibly not an uncommon scheme. Full EIT and OpenTV data is delivered for the SD channels, but only now/next for the HD versions. I guess Sky has some kind of way of linking the EPG data to both the SD and HD channels. TV Server isn't able to figure this out at present, so people end up combining channels and playing lottery over which version of the channel would be tuned and which version is used for the EPG.
Maybe your grabber is able to figure the above situation out. However consider a more subtle example of the same problem. Maybe one EPG source is richer than the other (episode and series link details available or something).
Maybe people want to combine the details from multiple sources (one source has better descriptions, the other has episode details).
What about enriching the EPG data using internet lookup.
What about accurate recording (CRID stuff).
What about constant now/next grabbing (eg. for radio stations that provide the current and next song details via the now/next data).
All of these things are floating around in my head...
The other issues that I was thinking of are mostly configuration related. For example, consider the following real-world problem.
Sky NZ has HD and SD versions of a bunch of channels. HD versions are available to those who pay for the "HD ticket"; those who don't pay get the SD versions. Possibly not an uncommon scheme. Full EIT and OpenTV data is delivered for the SD channels, but only now/next for the HD versions. I guess Sky has some kind of way of linking the EPG data to both the SD and HD channels. TV Server isn't able to figure this out at present, so people end up combining channels and playing lottery over which version of the channel would be tuned and which version is used for the EPG.
Maybe your grabber is able to figure the above situation out. However consider a more subtle example of the same problem. Maybe one EPG source is richer than the other (episode and series link details available or something).
Maybe people want to combine the details from multiple sources (one source has better descriptions, the other has episode details).
What about enriching the EPG data using internet lookup.
What about accurate recording (CRID stuff).
What about constant now/next grabbing (eg. for radio stations that provide the current and next song details via the now/next data).
All of these things are floating around in my head...
This is the entire reason I wish to move it into C# with modular support.
The TV Server will accept a standard input for EPG
Channel
Start Time
End Time
Title
Description
CRID
etc.
We then write modules/plugins that can decode the raw data stream and pass the data to the TV Server in the standard format.
We then can create/update provider support without massive updates to the TSwriter.
We would need an EIT/MHW decoder as standard but the others would be optional.
The only issue is getting the data from the TSWriter --> TV Server
Do we Marshall the data from C++ to C# or as I have in the custom data thread, write a seperate TS file with the data packets in it and read it from the TV Server. Or just write all the data along with the Video and Audio.
If there is an optional data file then other features such as MHEG5 could be added to the TV Plugins as the data is there to be used.
The TV Server will accept a standard input for EPG
Channel
Start Time
End Time
Title
Description
CRID
etc.
We then write modules/plugins that can decode the raw data stream and pass the data to the TV Server in the standard format.
We then can create/update provider support without massive updates to the TSwriter.
We would need an EIT/MHW decoder as standard but the others would be optional.
The only issue is getting the data from the TSWriter --> TV Server
Do we Marshall the data from C++ to C# or as I have in the custom data thread, write a seperate TS file with the data packets in it and read it from the TV Server. Or just write all the data along with the Video and Audio.
If there is an optional data file then other features such as MHEG5 could be added to the TV Plugins as the data is there to be used.
Last edited:
- September 1, 2008
- 21,577
- 8,224
- Home Country
-
New Zealand
Yes, this plugin style approach is what I have also used for the hardware support that I'm working on (DiSEqC, CAM, PID filter support etc.).
For example, consider the case where a person has access to multiple providers (not uncommon), and these providers have overlapping channel sets (again, not uncommon). In these cases, many people like to merge the channels. Which EPG source should be used though?
Have you ever looked at 4TR? I guess what I'm thinking of is their concept of an EPG source and the ability to link such a source with any channel at will. It is sorta like what the XMLTV plugin can do. This is quite different to a provider style approach where data is automatically linked to the right channels and you just configure the transponder to grab from. One approach is more like an STB (which many people like); the other seems more flexible to me.
Going forward I think traditional broadcast and bulk channel providers will still have their place for awhile, but more and more people are enjoying internet video streams. I would like TV Server to support generic internet streams that people currently have to use OnlineVideos for as channels of some description (with the associated recording and timeshifting abilities). Maybe that is pie in the sky type thinking, however my point is that in future I would like TV Server to be far more flexible about EPG sources and linkages.
I'm trying to understand if you are mentioning this because you think it will be easier for people to create plugins. Personally I don't see any reason why the EPG has to be handled in C# - TsWriter could have the interfaces and a plugin system, something like what has been done with the new DVB-IP filter design.
By "provider" here I understand you to mean [for example] Sky UK, or Sky NZ, or Canal Digitaal. Although I think there is absolutely a place for this, I'd also like our "ad-hoc" EPG support to be better.
For example, consider the case where a person has access to multiple providers (not uncommon), and these providers have overlapping channel sets (again, not uncommon). In these cases, many people like to merge the channels. Which EPG source should be used though?
Have you ever looked at 4TR? I guess what I'm thinking of is their concept of an EPG source and the ability to link such a source with any channel at will. It is sorta like what the XMLTV plugin can do. This is quite different to a provider style approach where data is automatically linked to the right channels and you just configure the transponder to grab from. One approach is more like an STB (which many people like); the other seems more flexible to me.
Going forward I think traditional broadcast and bulk channel providers will still have their place for awhile, but more and more people are enjoying internet video streams. I would like TV Server to support generic internet streams that people currently have to use OnlineVideos for as channels of some description (with the associated recording and timeshifting abilities). Maybe that is pie in the sky type thinking, however my point is that in future I would like TV Server to be far more flexible about EPG sources and linkages.
Do you consider the code language or managed vs. unmanaged as important?
I'm trying to understand if you are mentioning this because you think it will be easier for people to create plugins. Personally I don't see any reason why the EPG has to be handled in C# - TsWriter could have the interfaces and a plugin system, something like what has been done with the new DVB-IP filter design.
For me, the answer would have to be one that allows clean and efficient handling for time sensitive operations like constant now/next grabbing. Ideally there should be some decoupling between the real-time packet handling that TsWriter has to do and the full EPG data parsing and handling to avoid the possibility of any plugin affecting recording and timeshifting when EPG is grabbed. Whether it is desirable to write the EPG packets into a file to get this separation is something that I'm not certain about. This is the sort of decision I would ask other people on the team about.
I think MHEG applications should be considered separately as the data should go to the client (to allow per-client application interactions). If you are referring to plugins to strip the MHEG guide data out then that would be a different story. I note that currently teletext seems to be either handled by or parsed and cached on the server - I think that this handling should be moved to the client side as well.
- July 25, 2010
- 4,024
- 1,420
- Home Country
-
Germany
just a side note:
I have Sky Ger, so if I can provide any information to implement this great feature for Sky Ger let me know
I'm away from tomorrow on (see vacation thread), so don't be puzzled that I'm suddenly don't answer after my offer xD
I have Sky Ger, so if I can provide any information to implement this great feature for Sky Ger let me know
I'm away from tomorrow on (see vacation thread), so don't be puzzled that I'm suddenly don't answer after my offer xD
@miroslav22
I'm in the right thread now Come accross an issue whereby channel scanning causes a number of channels to merge where they should be seperate. Discussion between me and @mm1352000 here: https://forum.team-mediaportal.com/...s-with-same-name-in-to-single-channel.110246/
It does not happen with the native tv server but only with either your engine mods or @DJBlu engine mods. Not sure if it is intended or just a bug.
Also, I can confirm that altering the SkyUK custom grabber with NZ Sky stuff allows the EPG to pull down the full sky guide including HD channels.
It still populates with the leading [[xx]] in front of the program name but series link works fine. Perhaps you might consider adding it to your next release?
Thanks for the great work guys!
Chris
I'm in the right thread now
Come accross an issue whereby channel scanning causes a number of channels to merge where they should be seperate. Discussion between me and @mm1352000 here: https://forum.team-mediaportal.com/...s-with-same-name-in-to-single-channel.110246/It does not happen with the native tv server but only with either your engine mods or @DJBlu engine mods. Not sure if it is intended or just a bug.
Also, I can confirm that altering the SkyUK custom grabber with NZ Sky stuff allows the EPG to pull down the full sky guide including HD channels.
It still populates with the leading [[xx]] in front of the program name but series link works fine. Perhaps you might consider adding it to your next release?
Thanks for the great work guys!
Chris
Hi there,
Without seeing logs/your config, all I can do if guess.....
You might have some channels with the same tunning details, I believe the EPG funtion only populates the first occurence of that channel - So If you have selected to use the second/third/fourth occurence of a channel with the samer tuning details, then it wont show any EPG.
I dont believe the actual channel name matters, I think its just the tuning details that count for duplicate channels.
I could be well off - Hopefully a Dev could help
Like I said above, logs would help alot
J.
Without seeing logs/your config, all I can do if guess.....
You might have some channels with the same tunning details, I believe the EPG funtion only populates the first occurence of that channel - So If you have selected to use the second/third/fourth occurence of a channel with the samer tuning details, then it wont show any EPG.
I dont believe the actual channel name matters, I think its just the tuning details that count for duplicate channels.
I could be well off - Hopefully a Dev could help
Like I said above, logs would help alot
J.
Hi, I have been using DJBlu's excellent sky grabber for some time now, and thought I would give this one a go.
I have installed the 1.3a installer on page 1 and followed the page 1 instructions.
My question is: Can I delete all my channels and groups and let this grab all channels, redo the sky groups and EPG, etc, ie this will update everything so any sky changes will be reflected?
Kind regards.
I have installed the 1.3a installer on page 1 and followed the page 1 instructions.
My question is: Can I delete all my channels and groups and let this grab all channels, redo the sky groups and EPG, etc, ie this will update everything so any sky changes will be reflected?
Kind regards.
Hi there,
This version does not have all the features DJ's does (it has sky EPG and series link)
I tend to setup all my channels (with channel numbers) using DJ's, then export and import into Miroslav's version
J.
This version does not have all the features DJ's does (it has sky EPG and series link)
I tend to setup all my channels (with channel numbers) using DJ's, then export and import into Miroslav's version
J.
- Status