Messages

How does IceTV calculate its "Most Popular" rankings?

Code Select Expand

{
    "series_id": "121",
    "num_votes": "1088",
    "popularity_ratio": "1.00"
},
{
    "series_id": "26455",
    "num_votes": "1025",
    "popularity_ratio": "0.94"
},
In other words, how is the "num_votes" value calculated?

Is it the number of times that series is scheduled to record by IceTV users?

From what I can tell, the "popularity_ratio" is the "num_votes" for the series divided by the "num_votes" for the most popular series.  Is this correct?

Is the "Most Popular" data presented Australia-wide or for the user's local region?

How often is the "Most Popular" raking recalculated?

On the IceTV web site, there are filtering options for 'next 7 days', 'today', 'last 7 days' ... 'new series'.  Is there any way to apply these filters when using the JSON API?

During a JSON EPG request, would there be any benefit to adding the popularity data directly into any shows whose series also appear in the "Most Popular" list?  If an application wished to flag shows that are in the "Most Popular" list, as the system currently stands, it would need to fetch that list and match incoming EPG shows to the list.

I am not currently asking for any action to be taken.  I am trying to understand how this mechanism works.

What is ICETV's position regarding EPG data for '10 HD +1'?

Is the Kodi pvr.hts addon configuration pointing to the correct IP/Port?

Do you have a username/password set somewhere?

You can go into the TVH WebUI and enable logging, this will show any failed login attempts from Kodi.

This may suggest that TVHeadend is not running.

Check the Kodi log file for any error messages.

Anyone know why this is

My best guess would be duplicated services.

and how to fix it?

Browse to your IceBox:  http://<icebox_ip>:9981

Go into: Configuration | Channel / EPG | Channels.

Edit the channels in question to have the LCNs that you prefer.

You have a typo. The output is 3A.

Thanks.  Fixed.

There may be multiple hardware revisions.

Here is my IceBox label.



Here is my PSU label.



Input: 100-240V (AC) 50-60Hz 1A
Output:12V (DC) 3A (Centre Positive)

Good luck.

It has GET, PUT AND DELETE methods for /shows/timers/{timer_id}, but that's only used to delete and update timers (e.g. when they change status) on the server.

I just managed to dig out some very old Topfield source code and I have the following:

POST = Send a new timer to Ice.
DELETE = Delete an existing timer from Ice.
PUT = Update an existing timer on Ice.

I think that maybe PUT needs to be added to the documentation for clarification.

I don't use GET for timers because they are included by default with an EPG GET request.

So which HTTP method is correct depends on what you want to do.

OK, I think that you are onto something.

I think that maybe PUT is needed to update an existing record (like changing the status to 'pending', for example) and POST is needed to create a new one.  POST was always failing for me on update.

Hi Daniel,

Can you please check the API documentation?

http://developer.icetv.com.au/#!/Shows/post_shows_timers_timer_id

The request '/shows/timers{timer_id}' may be missing a '/'.  I think that it should be '/shows/timers/{timer_id}'.

Also, I think that the HTTP request method should be PUT, not POST.

Apologies in advance if I have misread something.

Thanks.  No rush.

If you have enough to spare, 2 please.

Do they still come with the little USB extender cables?

I'm happy for you to put them on my account for next month or I can call you with a credit card.  Just let me know.

Do IceTV still have any of their DVB tuners in stock?

[Would IceTV consider adding a feature that allows IceBox users to customise the format their own EPG content?]

Would IceTV consider adding a feature that allows IceBox users to customise the format their own EPG content?

The IceTV Kodi addon is written in the Python programming language.  It should be possible to call an external Python module from within the existing addon.

In its default configuration, the existing Kodi addon would remain relatively unchanged.  However, at startup, it would look for a user-defined Python module and set some flags if that module is found and is valid.

In the 'output_xmltv()' function, if the flags are true, service.icetv would then call those pre-defined external functions after the XMLTV object has been created, but before that object is converted to XML and sent to TVH.

This will allow the user to intercept and modify the XMLTV data before it is sent to TVH.

Because some data is critical, such as start/end times, these fields should not be customisable.

I suggest 3 functions in the external module for formatting 3 XMLTV elements:  'title', 'sub-title' and 'desc'.  Each of these modules would accept a single 'show' object as input and return a string containing the user-defined content for that field.

Once the module is initially loaded, each of the 3 functions can be tested for individually and flags set accordingly.

There would also need to be some try-except-else protection against syntax errors and the like within the user-defined module.

The existing Kodi addon would remain read-only in '/usr/share/kodi/addons/service.icetv'.  However, the external module would be located in '/storage/.kodi/userdata/addon_data/service.icetv/epg_formatter.py' (or similar) where it can be modified by the user.

I can post some code samples if this is of interest.

Under the hood, IceTV does not use the LCN to schedule recordings, it uses a string of characters (called a couplet?) to identify individual services within the transmission steam. It is only a problem if the couplet changes rather than the LCNs it is associated with, which does not appear to be the case here.

This is only partially true.

IceTV assigns a unique ID to each channel.  When a recording is sent to a PVR, it is sent referencing that unique ChannelID.

In the channels list, IceTV has a definition for each ChannelID, and part of that definition includes the DVB triplets (ONID, TSID & SID) as well as the LCN.

Code Select Expand

        }, {
            "id": "3",
            "name": "7 Digital",
            "name_short": "Seven",
            "network_id": "9",
            "region_id": "1",
            "is_hd": 0,
            "lcns": "7,71",
            "region_name": "NSW - Sydney",
            "network_name": "Seven",
            "is_hidden": 0,
            "icon_src": "https://images.icetv.com.au/channels/seven-v2.png",
            "icon_width": 0,
            "icon_height": 0,
            "is_capital_channel": false,
            "dvbt_info": [{
                    "original_network_id": "4115",
                    "transport_stream_id": "1282",
                    "service_id": "1312",
                    "lcn": "7",
                    "frequency": "0"
                }, {
                    "original_network_id": "4115",
                    "transport_stream_id": "1282",
                    "service_id": "1313",
                    "lcn": "71",
                    "frequency": "0"
                }
            ]
        }, {
When determining which actual channel to record, the PVR needs to look at the ChannelID provided, find the DVB triplets or LCN for that channel and then perform a match.

If the PVR matches on the DVB triplets, there is not a problem, because they have not changed.  However, if the PVR matches on the LCN, then an error may occur.  Perhaps the PVR does neither and tries to match on the channel name.

This issue will come down to how the PVR firmware matches IceTV channels to the DVB Services that it receives.

This analysis is based on the newer JSON API.  I did reverse engineer the old binary API that Topfield PVRs use a long time ago, but I don't remember what matching criteria are provided for channels, it may be LCN-based.