oztoppy Forum
Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment   Page 1 of 3      1   2   3   Next
DeltaMikeCharlie

Mostly Harmless
Registered:
Posts: 249
Reply with quote  #1 
I am thinking about writing a TAP that will enable any Topfield TMS PVR to be able to use the new ICE TV XML EPG feed.  I am currently NOT considering keyword/timer integration in phase 1, EPG only.

I would like to know how many users would find this feature useful.  To be clear, models that currently DO NOT support ICE TV (like the 7160) would now be able to do so using this TAP.  Models that already support ICE TV will need to have ICE disabled in their firmware settings.

To use this feature, users would need to run the TAP as well as subscribe to the ICE TV service.

The main reason for doing this is to allow the additional EPG data provided by ICE TV to be able to be used.  For example, the following additional information is available:

Series ID (ICE Unique)
Episode ID (ICE Unique)
Credits (Actors, producer, director, etc)
Production year
Enhanced genre information
Country of origin
Season+Episode (eg: S01E01)
Repeat flag
Star rating

This additional information would be included in the body of the EPG description, for example:

Sheldon takes the direct route when he can't seem to get past a physics conundrum by trying different modes of thought. He's even making cheesecake.(United States, English) +repeat:yes,  +cat:Comedy, +cat:Sitcom, +act:Johnny Galecki, +act:Jim Parsons, +act:Kaley Cuoco, +act:Kunal Nayyar, +act:Simon Helberg, +act:Yeardley Smith, +rating:G, +country:United States, +language:English, +series:11961, +episode:84877, +date:2010

This information could also be fed into SmartEPG.  This would allow SE searches to more accurately include or exclude programmes.  For example, within SE, adding a "-99" search in the extended description for "+repeat:yes" would exclude repeated episodes from being recorded.

At the moment, it appears that existing PVR accounts can not be converted to the new system.  Users would need to set them up from scratch again.  This is because of the way the revised authentication and device identification protocol works.  It may be possible to "import" from an old system, but this would be a phase 2+ feature.

0
IanL-S

Moderator
Registered:
Posts: 605
Reply with quote  #2 
This would be useful. I have a 2470, 7160 and 2 x 7260 on which I could use the TAP.

Ian
0
davidmorr

Senior Member
Registered:
Posts: 177
Reply with quote  #3 
I must admit to being frustrated at the way ICE currently works. The website shows info that the toppy doesn't, and vice versa. Info about conflicts is random and unhelpful. Some of this is dependent on ICE's systems, but perhaps it is the old API and the new one is better?

That said, my 2400 is flakey enough that I will probably abandon it within the next 12 months, or when it next plays up, whichever is the sooner :-)

So while something that works better would be wonderful, unless the toppy cleans up its act, it will be replaced by Beyonwiz.

[Hmmm, I wonder whether Beyonwiz uses the old or new API? Will I have to close my account and create a new one for it?]
0
AQUAR

Member
Registered:
Posts: 75
Reply with quote  #4 
I have a TRF-7160 and interested in such a TAP.
0
DeltaMikeCharlie

Mostly Harmless
Registered:
Posts: 249
Reply with quote  #5 
Quote:
Originally Posted by davidmorr
[Hmmm, I wonder whether Beyonwiz uses the old or new API? Will I have to close my account and create a new one for it?]

A Beyonwiz developer is very active on the ICE and Beyonwiz forums.  He appears to be working on integrating the new API, but I'm not sure what his progress is as well as which models he is targeting.

You won't need to close your ICE account because you are entitled to use multiple (5, I think) PVRs.  You can get the new BW configured and then delete the Topfield.
0
IanL-S

Moderator
Registered:
Posts: 605
Reply with quote  #6 
The T2, T3, T4 and U4 use the same IceTV API (not sure if the IceTV SKIPPA uses that API or a newer one); it is more recent than the IceTV API used by Toppys and earlier Beyonwiz models. Given the number of recording slots (8 for the T2 and 10 for the T4 and U4) you are less likely to get clashes. Also, the implementation on Toppys is badly broken, it has difficulty in dealing with minor changes in start and finish times (this is not an IceTV API issue).

You can have up to 5 devices on an IceTV account, and they can use different IceTV API.

Ian
0
IanL-S

Moderator
Registered:
Posts: 605
Reply with quote  #7 
If the TAP is ultimately extended to include Timers I would use the TAP rather than Toppy implementation on my 2400/5300/7100+.

Ian
0
DeltaMikeCharlie

Mostly Harmless
Registered:
Posts: 249
Reply with quote  #8 
Quote:
Originally Posted by IanL-S
You can have up to 5 devices on an IceTV account, and they can use different IceTV API.

True, but it should be noted that all devices have their channels restricted by your ICE global settings.  If you have removed EPG data from certain LCNs to stop your Topfield(s) from rebooting, those LCNs are also removed from other PVRs/APIs on the same account.
0
DeltaMikeCharlie

Mostly Harmless
Registered:
Posts: 249
Reply with quote  #9 
Quote:
Originally Posted by IanL-S
If the TAP is ultimately extended to include Timers I would use the TAP rather than Toppy implementation on my 2400/5300/7100+.

I am thinking about timers, but there are a number of issues to overcome, especially when SE integration is taken into account.

I think that SE does a much better job than ICE of matching/rejecting shows to record.  However, SE only does this once a day and ICE does it more frequently.  ICE is also a centralised interface for setting timers remotely, however, your PVR must be on to accept those changes or to use WebControl if you want to stick with a non-ICE remote timer solution.

Do to variable Australian network broadcast times, I like to merge multiple sequential recordings into a single timer with abundant padding where possible.  Using INFPlus makes navigation these recordings easy.

Unfortunately, ICE use the logic of recording a "Show", not for a period of time.  One timer equals one show.

When there are multiple shows merged into a single timer on the PVR, there needs to be a way to spoof multiple timers back to ICE so that it registers that every single "show" is being correctly recorded.

Lastly, ICE generates a very long unique timer ID that is too long to store in the Topfield timer structure so a lookup table will be required and a reference stored in an "unused" field.  If SE merges one of these timers, the external reference could be lost and the Topfield/ICE synchronisation thrown into disarray.

I am thinking that I will not be able to do any exact 1:1 timer matching.  Instead, when a timer is created on the PVR that spans multiple whole shows, I will need to send multiple timer records to ICE.  Conversely, when an ICE timer arrives, I will need to test PVR timers for channel/start/duration overlap.  There is also the complication with recurring timers, ICE timers are "OT" only.  If there is a "Daily" (etc) PVR timer, the TAP will have to spoof multiple "OT" timers back to ICE.

Back on to EPG for a moment:

I am thinking that I will download the whole EPG once per day and then download changes only at regular intervals.  The intervals will be parameterised (let's say 15 minutes).  Every 15 minutes, the TAP will check to see the last time the full EPG was fetched.  If it is greater than 24 hours (or whatever) then do a full fetch, else do an incremental fetch.

Timer synchronisation would be aligned to the EPG update interval.

So you will be able to control: 1) How often (minutes) the PVR looks for new EPG data and synchronise timers and 2) How often (hours, 24=daily, 168=weekly, etc) the PVR totally refreshes its EPG data.

Thoughts?  Comments?  Opinions?
0
IanL-S

Moderator
Registered:
Posts: 605
Reply with quote  #10 
EPG considerations
The major drawback of TMS timer (compared to IceTV) is the once-a-day EPG search. So, from that standpoint, IceTV has a major advantage. Give the frequency of updates to the IceTV data base checking every 15 minutes is possibly overkill - although I understand that the Beyonwiz IceTV plugin has minimum check time of 15 minutes. I know many users prefer to put their Toppys into standby when not using them, so the user needs to take this into account when they do so. When I am away from home for extended periods I put the Toppys into standby mode and have one of two P timers set late in the afternoon to pick up late EPG changes. Is it possible to include an option in the TAP to bring the Toppy out of standby at either predefined time(s) each day or after predefined period? 

One problem with Toppy IceTV implementation is if when the Toppy boots-up it cannot contact the IceTV Server it stops checking. Last week I had a power outage (tree fell on power lines) and I lost power and the Telstra Cable went out. The Telstra cable came back up about an hour after the power was restored so the Toppys did not have any EPG data. The timers were still there but there was no information in the inf file created by them. The Beyonwiz did not have this problem, although the U4 had a corrupt timer data base so all timers were lost. 

Timer considerations
Owning to the way Toppys allocate timers to tuners, like you I manually combine consecutive turners and rely on infPlus. One advantage of using SmartEPG is that it (as I understand it) allocates consecutive timers to different recording slots (this requires a firmware hack) if you do not combine the recordings. If you use IceTV and manually combine timers you run the risk that the timer will be replaced with one just for the one program (these are usually timers created automatically by IceTV). For this reason I do manual combines late in the afternoon. I am not sure how using IceTV EPG data with SmartEPG deals with combined timers - but if it is capable of dealing with EPG data updates that will be good (I must admit I have not tried integration of IceTV EPG and SmartEPG.

One thing I like about IceTV is the ability to set, delete, timers when I am away from home. However, I can see that this is something that is considerably more difficult to implement. 

Odd topic
One thing that I would like would be the ability to use recording slot allocated to time-shift to timers when the time-shift is disabled. I really should raise this possibility with FireBird.

Ian
0
DeltaMikeCharlie

Mostly Harmless
Registered:
Posts: 249
Reply with quote  #11 
I have a daily "P" timer set in the early morning to get ICE EPG data at least once a day.  The iceConnect TAP could also create one automatically like SE does, perhaps even several at nominated times.  Perhaps in phase III.  Manual "P" timers would be almost as good as users could customise them to their "normal" viewing times and habits.

I'm not sure if SE will merge "Manual" (created external to SE) timers or if it will only merge timers that it matched.  Some quick testing suggests that it will not merge manual timers because "Allow Combine=No" whereas SE timers show "Allow Combine=Any Timer".

In WebControl, I wrote a command-line utility that actually does the EPG searching for the "EPGSearch" module.  This utility could be modified to search the ICE EPG data as it arrives and create timers as required.  The utility deliberately uses the same format as SE's search file so executing SE searches regularly on incremental ICE data "should" be semi-trivial.  -> Phase IV.

The ultimate solution would be to have SE modified so that external TAPs can trigger incremental EPG imports and background searches.  This would be overkill IMHO.

TMS is dead and consideration needs to be given to effort vs benefit.  A small effort to get ICE EPG data into the PVR could be justified, but anything more than that may be questionable.  Phase I may not even have a config screen, it may be configured manually using an INI file and text editor.
0
davidmorr

Senior Member
Registered:
Posts: 177
Reply with quote  #12 
Quote:
Originally Posted by DeltaMikeCharlie
TMS is dead and consideration needs to be given to effort vs benefit.  A small effort to get ICE EPG data into the PVR could be justified, but anything more than that may be questionable.  Phase I may not even have a config screen, it may be configured manually using an INI file and text editor.
I must admit I wondered if it would be worth the effort. If the goal is to get ICE EPG into SmartEPG, Firebird made that work a couple of years ago. The capability may still be there.

0
DeltaMikeCharlie

Mostly Harmless
Registered:
Posts: 249
Reply with quote  #13 
Quote:
Originally Posted by davidmorr
Firebird made that work a couple of years ago.

Can you please provide some more details about this feature?
0
davidmorr

Senior Member
Registered:
Posts: 177
Reply with quote  #14 
Sent PM
0
DeltaMikeCharlie

Mostly Harmless
Registered:
Posts: 249
Reply with quote  #15 
Quote:
Originally Posted by davidmorr
Sent PM
Thanks for the PM.  The transcript that you sent me was very long with lots of repetitive sections, but I was able to get the gist of it.

In short, it appears that the ICE EPG data that is converted for SmartEPG use is read from the EPG disk cache.  This cache contains the EPG data as at the last time the PVR was cleanly powered-off.  To the best of my knowledge, changes since power-on are not captured, the cache is only written at power-off.

The EPG file cache exists so that the PVR can reload its EPG data at power-on without having to rescan every network.  FireBird may have a firmware hack that forces the EPG data in memory to be saved to disk before the TAP runs.  However, if this is not the case then the EPG data will as old as the last clean power-down.

Considering the timeframe (June/July 2013), I find it strange that FireFird would not just read the EPG data directly from memory because the EPGInfo function were fairly mature by mid 2013.

I will contact FireBird and ask for the source for this TAP, and investigate further.
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.