TuneIn

[Altheran 0]

Hi @LukeI have the same issue, I am in Canada and have specified coordinates near Montreal. I got the Alberta stations, but all other provinces are empty.
Last time I checked at this ... a few months ago, I could go trough all "folders" with stations available.

[Luke 42077]

8 hours ago, Altheran said:

Hi @LukeI have the same issue, I am in Canada and have specified coordinates near Montreal. I got the Alberta stations, but all other provinces are empty.
Last time I checked at this ... a few months ago, I could go trough all "folders" with stations available.

As far as I know this is just the way the tunein api works, that not all content is available through it.

[jonbranson76 0]

Hi....just started playing with the TuneIn addon but i seem to be having issues as i have the various top-level folders but they are all empty including the By Location one.

I have entered my username and location and just username but no change. The refresh internet channels option in the settings seems to run but is done in 6 seconds and hasnt made a difference. Not 100% sure what i need to do to get it working. Any help would be appreciated. 

[CJTripper 17]

It would appear that when the plugin sync's (can be manually triggered by Scheduled Tasks->Refresh Internet Channels), the plugin script successfully starts to enumerate the info being received from the Tunein target server - but then stops receiving data and fails to continue because the Tunein target server quits sending data. In the Emby event logs, you will see Http response 429 messages being sent from the Tunein server: TooManyRequests. 

So it appears to me that a pause or delay would have to be added to the plugin's code (likely between enumerating each folder as some can be large - "outline text" tag in the server data output) so the Tunein server doesn't stop the repeated queries with a http 429 error for TooManyRequests. Or maybe a counter to pause after a set number of queries. Or maybe change the enumeration loops from async to sync so multiple enumerations are not occurring at the same time?  I have no idea what the threshold or timeout is set to on the Tunein server. Likely some kind of DDoS attack prevention configuration set up on their servers.  I recall back years ago the sync used to take hours...maybe that was an older version of the plugin and it was slow for a good reason!!

The modifying of the source code is a little over my head, so I don't think I'll be able to resolve this...at least not on my own, but I'm willing to provide additional info and testing if anyone else wants to dig into tweaking the source code and compiling it.

A couple other items to note:

1. USERNAME: I confirmed the Tunein servers will accept the username field from this plugin as either your Tunein USERNAME or EMAILADDRESS. I successfully returns your "favorites" using either as your account identifier. But do note that your Tunein account settings must have your Favorites set to "public profile". As the plugin is not authenticating with your Tunein password, it will not be able to retrieve your Favorites if your Favorites are set to "private profile" in your Tunein account settings. Favorites is one of the first items sync'd by the plugin.

2. YOUR LATLON: This field seems to get appended to most of the queries ran by the plugin. As a workaround, I adjusted my LATLON field in the plugin to try limit/filter the query results to only local stations with the &c=local parameter. For example, Toronto, Canada could use a LANLON field of: 43.653225,-79.383186&c=local  . I am still experimenting with this a bit using curl commands from the command line, lots of good info posted here for any others interested: GitHub - core-hacked/tunein-api: Unofficial documentation of TuneIn's Streaming API. (opml.radiotime.com)

 

Edited January 9 by CJTripper

[Luke 42077]

On 1/8/2026 at 9:12 PM, CJTripper said:

It would appear that when the plugin sync's (can be manually triggered by Scheduled Tasks->Refresh Internet Channels), the plugin script successfully starts to enumerate the info being received from the Tunein target server - but then stops receiving data and fails to continue because the Tunein target server quits sending data. In the Emby event logs, you will see Http response 429 messages being sent from the Tunein server: TooManyRequests. 

So it appears to me that a pause or delay would have to be added to the plugin's code (likely between enumerating each folder as some can be large - "outline text" tag in the server data output) so the Tunein server doesn't stop the repeated queries with a http 429 error for TooManyRequests. Or maybe a counter to pause after a set number of queries. Or maybe change the enumeration loops from async to sync so multiple enumerations are not occurring at the same time?  I have no idea what the threshold or timeout is set to on the Tunein server. Likely some kind of DDoS attack prevention configuration set up on their servers.  I recall back years ago the sync used to take hours...maybe that was an older version of the plugin and it was slow for a good reason!!

The modifying of the source code is a little over my head, so I don't think I'll be able to resolve this...at least not on my own, but I'm willing to provide additional info and testing if anyone else wants to dig into tweaking the source code and compiling it.

A couple other items to note:

1. USERNAME: I confirmed the Tunein servers will accept the username field from this plugin as either your Tunein USERNAME or EMAILADDRESS. I successfully returns your "favorites" using either as your account identifier. But do note that your Tunein account settings must have your Favorites set to "public profile". As the plugin is not authenticating with your Tunein password, it will not be able to retrieve your Favorites if your Favorites are set to "private profile" in your Tunein account settings. Favorites is one of the first items sync'd by the plugin.

2. YOUR LATLON: This field seems to get appended to most of the queries ran by the plugin. As a workaround, I adjusted my LATLON field in the plugin to try limit/filter the query results to only local stations with the &c=local parameter. For example, Toronto, Canada could use a LANLON field of: 43.653225,-79.383186&c=local  . I am still experimenting with this a bit using curl commands from the command line, lots of good info posted here for any others interested: GitHub - core-hacked/tunein-api: Unofficial documentation of TuneIn's Streaming API. (opml.radiotime.com)

 

Hi, please try version 1.2.7 of the TuneIn plugin. I've added some basic rate limiting to space the requests out. Thanks.

[CJTripper 17]

@Luke,

Thanks for taking the time to look into this and attempt a fix. I did a quick test of the new plugin version:

The change you made for plugin v1.2.7 slowed the queries down a little bit, but we are still getting "Http response 429" (too many requests) after the first 20 successful queries to the TuneIn server. Before your change (plugin v1.2.6), it was processing the 20 queries in about 2 seconds (10 queries/sec), now it processes those 20 queries in in 10 seconds (2 queries/sec). Both now and before, it would Http response 429 on the remaining requests (approx 20 more that fail), those also occur at the rates noted above (2 queries/sec with new version, 10 queries/sec with old version).

It would appear the "50 queries/second limit" comment in the source code has changed and that rate is no longer applicable for the TuneIn Server. Even the 2 queries/sec seems to be too high. I'm thinking maybe we have to go slower yet, I remember many years ago when they plugin would successfully complete it's sync, it would take HOURS for the full sync to complete (not sure how many total queries it does, I would guess thousands for the full enumeration if successfully populating everything).

I attached a snip from my Emby server log for your reference to see what is happening during processing with the new version of the plugin.

I have a test server setup if you want to PM me some plugin .dlls with some different rates for me to test with (if you are willing). Sorry, I don't know how to compile the source code myself...something I'll have to teach myself I guess.  Thanks!!

embyserver_RefreshInternetChannels_TuneInPlugin.txt

Edited January 12 by CJTripper

[CJTripper 17]

On 11/10/2025 at 9:47 AM, Altheran said:

Hi @LukeI have the same issue, I am in Canada and have specified coordinates near Montreal. I got the Alberta stations, but all other provinces are empty.
Last time I checked at this ... a few months ago, I could go trough all "folders" with stations available.

The queries enumerate (expand results of previous queries to generate new queries), so when you launch a sync in Montreal, Canada, it processes the queries in the order below (if you are trying to follow along in your embyserver log):

1. query to determine TuneIn groups available

2. query with latlon or c=local parameter (the response determines what country you are in): So your response would have: <outline type="link" text="All Canada" URL="http://opml.radiotime.com/Browse.ashx?id=r101227" key="localCountry"/>

3. query with TuneIn userid (if populated in the plugin, gets your personal favorites from TuneIn servers)

4. queries to start enumerating regions for the country identified in query #2 above (queries r101227 for Canada, which responds with provinces. As Alberta is the first province returned in the Canada query, it is the first to be enumerated). Thus why only most of Alberta gets populated before the TuneIn server stops responding for "too many queries" and the sync fails.

From a command line on your computer (Windows CMDs below), you can run the quieries yourself manually to see what responses you get from the TuneIn Server:

1. curl -s -X GET "https://opml.radiotime.com/browse.ashx"

2. curl -s -X GET "http://opml.radiotime.com/Browse.ashx?c=local&formats=mp3,aac"

3. curl -s -X GET "http://opml.radiotime.com/Browse.ashx?c=presets&formats=mp3,aac&partnerid=uD1X52pA&username=YOURTUNEINUSERNAME"

4. Canada = curl -s -X GET "http://opml.radiotime.com/Browse.ashx?id=r101227

5. Alberta = curl -s -X GET "http://opml.radiotime.com/Browse.ashx?id=r100447

And on it goes...it would enumerate through all the provinces and cities if not failing because of "too many queries" error 429. The sync script also does some filtering which gives you separate folders for genres, etc. Using the curl commands above, you will be able to find id numbers for locations and links for stations manually. id=r0 will start you at the very top of the locations and respond with the info for the continents.

[CJTripper 17]

@Luke- forget about compiling the plugin .dll for me. I gave myself a crash course on Visual Studio and can now compile myself and am testing now.

Slowed it to 1 query per second, and it still triggering http response 429 - Too many requests.

Slowed it to 1 query per 5 seconds, it is still processing queries after 20 minutes and has made it past Alberta and is now syncing British Columbia on the Canada region.

So I think I have the solution, I'll play around to find the "sweet spot" for max query speed without triggering http 429. Populating everything is going to take a long time, I guess a possible feature to add might be to add some filtering (perhaps some fields in the plugin config we could add for "local only" or the option to limit enumeration to a continent/country/region) - for those who don't want to wait hours for it to sync all stations. I'm not a coder so won't make any promises.

I'll report back with the max query speed I find.

[CJTripper 17]

OK, so 1 query per every 3 seconds seems to be a stable query rate (requestIntervalMs = 3000). At 2000 and 2500, the TuneIn server was inconsistently throwing http response 429 still.

Enumerating the "Local Radio" (All Canada) folder/subfolders took 45 minutes for the ~920 queries to complete them all successfully. It then started to enumerate the "Music" folder, after an hour it was still enumerating the first genre folder and went down a rabbit hole of enumerating deeper into nested "More Channels" folders within it. I'm sure it would have ran for hours/days/weeks if I didn't stop it. And after "Music" it would have next enumerated the folders: Talk, Sports, By Location, By Language, Podcasts....then would jump out of the enumeration to grab My Favorites.

I personally didn't need anything more than my Local Radio (All of Canada including Provinces and Cities) and My Favorites. So I found adding &c=local to my latlon field in the plugin will skip the root of the enumeration from Local Radio,Music,Talk, Sports, By Location, By Language, Podcasts; and will instead starting the enumeration with the Local Radio as the root and will skip those other folders. Then once complete it successfully grabs the Favorites. So for example in Toronto, Canada - the following entry into the latlon field of the plugin would get you 2 fully populated root folders: Local Radio with all the channels in Canada + Favorites:  43.653225,-79.383186&c=local

My personal testing plugin .dll is version 1.2.7.1, please PM me if it is required for testing. Not my plugin so I don't want to post the compiled version. Hopefully @Lukecan set this 3000 delay in the git source code and compile an updated version of the plugin for proper release through Emby install/update mechanisms.

I don't think I'll be going any further into the code re-write (other than possibly hardcoding/forcing the &c=local on the latlon variable). Due to the TuneIn server requiring query delays to enumerate everything, it no longer seems feasible to be using a global scope for those other folders. I'm thinking we either just continue to use it to get "Local Channels" and Favorites as I am above, or someone needs to give the plugin a serious re-write to be more focused and reduce the massive amount of enumeration required.

[Luke 42077]

OK please try version 1.2.8 of the plugin. Thanks.

[CJTripper 17]

I updated to version 1.2.8 and can confirm after 12 hours of "updating internet channels" it is still successfully sending queries, receiving responses, and populating additional channels. The 1 query per 3 seconds appears to have resolved the http 429 - too many requests issue.

However - be aware of a few things:

1. the progress bar does not move on the "updating internet channels". You would have to look at the log to confirm it is still processing, or occasionally check in the TuneIn folder to see that additional groups are still being populated.

2. It first populated my "Local Channels" in about 45 minutes (for Canada), then started on the Music folder. After 12 hours it has 16 of the 25 Music genre folders populated. Expect a very long time (days) for the full sync to complete.

For those that only want to populate their "Local Channels" and "My Favorites", I still recommend appending &c=local to the end of your latitude/longitude field in your TuneIn Plugin settings, so it only sync's those 2 folders. It should populate your "Local Channels" (your country) within a few hours. For example, someone in Toronto would use 43.653225,-79.383186&c=local  and their "Local Channels" becomes "All Canada" with 13 province sub-folders populated. I have not tested for any other countries but assume it would work the same when run from a different location with those lat/long numbers entered. I believe the &c=local in the query is using geo tracking to determine the location and query results for the "Local Channels", not necessary the lat/long actually entered in the plugin settings. I haven't tested, but assume you would have to run through a VPN to another country ISP during the "Internet Channels Update" if you wanted your "Local Channels" from another country.

My thanks to Luke for updating the delay and releasing the new plugin version!

[CJTripper 17]

Just to set some expectations for those running the full sync - expect 3 days for the full sync to proceed in this order (these were my times from a Canada location):

1. Local Channels = 45 min (for All Canada)

2. Music = 13 hrs

3. Talk = 23 hrs

4. Sports = 3.5 hrs

5. By Location = 23 hrs

6. By Language = 30 min (English)

7. Podcasts = 6.5 hrs

8. Favorites = 1 min

At the rate of 20 queries per minute (1 query per 3 seconds), that was roughly 86000 queries for my full sync!

[horstepipe 422]

same here,

the "refresh internet channel" schedule task now runs 24/7...

[Luke 42077]

7 minutes ago, horstepipe said:

same here,

the "refresh internet channel" schedule task now runs 24/7...

Unfortunately that is the consequence of rate liming data requests to once every 3 seconds.

[brietman 1]

2 hours ago, horstepipe said:

same here,

the "refresh internet channel" schedule task now runs 24/7...

I found out the hard way that this was a issue. Restored a Home Assistant backup after a migration. Everything got well, except Emby:

Exception of type 'SQLitePCL.pretty.SQLiteException' was thrown

Restored an older backup. No change. Saw 'refresh internet channel'. Uninstalled Tune In. No change. Vacuum did nothing. Terminal command said it was malformed. Metadata also still shown, instead of removed. Started my old HA instance. Removed TuneIn. Made new backup and restored it. Everything went well. 

[CJTripper 17]

I suppose people should also check their Scheduled Tasks->Refresh Internet Channels if running a TuneIn full sync. You would likely want to change the scheduling frequency to weekly if it will take days just to do a single iteration of the full sync of TuneIn. But this would affect other Internet Channel plugins refreshes that you may also have installed, so I guess you have to do whatever suits your setup. Also note you can set time limits in the Scheduled Tasks, or manually stop the Refresh Internet Channels...if you need to.

Personally, I am appending the &c=local to my lat/long field to limit my TuneIn sync to my country only, which keeps my TuneIn sync to under 1 hour, although I now won't get the additional folders, only have my Local Channels and Favorites now. Good enough for me.

With the delay required for the TuneIn server to continue responding to the queries, it would seem our only options are to wait the time, or for someone to find an alternate source/server that allows faster queries, or for someone to rewrite the plugin to allow for more filtering options to reduce the enumeration and number of queries (and thus reduce sync time). A rewrite is beyond my coding capabilities, so sorry to say that I think I've went as far with this one as I am able to.

Edited January 30 by CJTripper

[Sibasiach 2]

Would “&c=location” only synchronize By Location + Favorites ?

[CJTripper 17]

Hey @Sibasiach

Appending "&c=location" to the LatLon field fails:

        <status>400</status>
        <fault>Invalid root category</fault>

I think you will want to append &id=r0 AFTER your LatLon value in the LatLon field of the plugin to get the "By Location" as the root/seed folder of the enumeration (+ Favorites runs in a separate query from the enumeration loop so Favorites should populate also):

C:\Users\REDACTED>curl -s -X GET "https://opml.radiotime.com/browse.ashx"

<?xml version="1.0" encoding="UTF-8"?>
<opml version="1">
        <head>
        <title>Browse</title>
        <status>200</status>

        </head>
        <body>
<outline type="link" text="Local Radio" URL="http://opml.radiotime.com/Browse.ashx?c=local" key="local"/>
<outline type="link" text="Music" URL="http://opml.radiotime.com/Browse.ashx?c=music" key="music"/>
<outline type="link" text="Talk" URL="http://opml.radiotime.com/Browse.ashx?c=talk" key="talk"/>
<outline type="link" text="Sports" URL="http://opml.radiotime.com/Browse.ashx?c=sports" key="sports"/>
<outline type="link" text="By Location" URL="http://opml.radiotime.com/Browse.ashx?id=r0" key="location"/>
<outline type="link" text="By Language" URL="http://opml.radiotime.com/Browse.ashx?c=lang" key="language"/>
<outline type="link" text="Podcasts" URL="http://opml.radiotime.com/Browse.ashx?c=podcast" key="podcast"/>
        </body>
</opml>

It isn't really a proper filter, it was just dumb luck that I found adding the &c=local  to the LatLon field of the plugin returned only the "Local Channels" folder in the initial root/seed query, so only it was enumerated, then the "My Favorites" sync's separately from the enumeration part of the script. Note that using &c= or &r= values in the plugin LatLon field does not work on or affect queries within the enumerations, as many of those enumeration queries already have a c= or r= value in them, so anything we enter (which is appended to the end of the query string) is ignored and the other value is used. It only seemed to affect that initial query where it finds all the folders to enumerate, with appending &c=local returning only "Local Channels" folder.

I tried with appending &id=r101218 (for North America) after my LatLon value, it seeded the North America countries as the root of the enumeration and created folders in the root of the TuneIn plugin folder for each country in North America and synced them (as well as my Favorites after). No folders for Music, Talk, Sports, By Location, etc.

Below are some seed values for &id=rXXXXXX if you want to try it. Note you can drill down farther into other continents/countries/states/provinces/etc with additional curl queries. Example below is how I found North America id=r101218.

C:\Users\REDACTED>curl -s -X GET "http://opml.radiotime.com/Browse.ashx?id=r0"
<?xml version="1.0" encoding="UTF-8"?>
<opml version="1">
        <head>
        <title>By Location</title>
        <status>200</status>

        </head>
        <body>
<outline type="link" text="Africa" URL="http://opml.radiotime.com/Browse.ashx?id=r101215" guide_id="r101215"/>
<outline type="link" text="Asia" URL="http://opml.radiotime.com/Browse.ashx?id=r101216" guide_id="r101216"/>
<outline type="link" text="Australasia" URL="http://opml.radiotime.com/Browse.ashx?id=r100297" guide_id="r100297"/>
<outline type="link" text="Central America" URL="http://opml.radiotime.com/Browse.ashx?id=r101320" guide_id="r101320"/>
<outline type="link" text="Europe" URL="http://opml.radiotime.com/Browse.ashx?id=r101217" guide_id="r101217"/>
<outline type="link" text="North America" URL="http://opml.radiotime.com/Browse.ashx?id=r101218" guide_id="r101218"/>
<outline type="link" text="South America" URL="http://opml.radiotime.com/Browse.ashx?id=r101219" guide_id="r101219"/>
        </body>
</opml>
-------------------
C:\Users\REDACTED>curl -s -X GET "http://opml.radiotime.com/Browse.ashx?id=r101218"
<?xml version="1.0" encoding="UTF-8"?>
<opml version="1">
        <head>
        <title>North America</title>
        <status>200</status>

        </head>
        <body>
<outline type="link" text="Bermuda" URL="http://opml.radiotime.com/Browse.ashx?id=r100306" guide_id="r100306"/>
<outline type="link" text="Canada" URL="http://opml.radiotime.com/Browse.ashx?id=r101227" guide_id="r101227"/>
<outline type="link" text="Caribbean Islands" URL="http://opml.radiotime.com/Browse.ashx?id=r101162" guide_id="r101162"/>
<outline type="link" text="Greenland" URL="http://opml.radiotime.com/Browse.ashx?id=r100348" guide_id="r100348"/>
<outline type="link" text="Mexico" URL="http://opml.radiotime.com/Browse.ashx?id=r101271" guide_id="r101271"/>
<outline type="link" text="St. Pierre-Miquelon" URL="http://opml.radiotime.com/Browse.ashx?id=r100419" guide_id="r100419"/>
<outline type="link" text="United States" URL="http://opml.radiotime.com/Browse.ashx?id=r100436" guide_id="r100436"/>
        </body>
</opml>
 

Sorry...I understand how it all works in theory, but I don't possess the coding skills to customize the plugin interface to add additional functionality to filter/customize the plugin to more specific queries. I was thinking something like check boxes in the interface for which containers or continents that the script would individually enumerate, instead of the enumeration just starting at the root of the containers and syncing everything. A competent programmer might be able to do it easily, but that is beyond my skillset, I'll just have to stick to my "appending to LatLon field workaround" for now I guess! And in all fairness to the plugin author, it likely wasn't an issue to sync everything until the TuneIn servers started limiting the queries to 1 every 3 seconds. I think I seen the plugin was initially doing 50 queries per second, so we are syncing 150x slower than it used to sync at (now 3 days for a full sync vs 30 minutes previously).

[Sibasiach 2]

On 7.2.2026 at 20:33, CJTripper said:

Hey, Hey @Sibasiach

Das Anhängen von "&c=location" an das Feld LatLon schlägt fehl:

<status>400</status>
<fault>Ungültige Stammkategorie</fault>

Ich denke, Sie möchten Ihren LatLon-Wert im LatLon-Feld des Plugins an Ihren LatLon-Wert anhängen &id=r0 , um das "Nach Standort " als Root/seed-Ordner der Aufzählung zu erhalten (+ Favoriten werden in einer separaten Abfrage aus der Aufzählungsschleife ausgeführt, so dass Favoriten auch gefüllt werden sollten):

C:\Users\REDACTED>curl -s -X ERHALTEN Sie "https://opml.radiotime.com/browse.ashx"

<? xml version="1.0" encoding="UTF-8"? >
<opml version="1">
<Kopf>
<title>Durchsuchen</title>
<status>200</status>

</head>
<body>
<outline type="link" text=" Local Radio " URL="http://opml.radiotime.com/Browse.ashx? c=lokal " key="local"/>
<outline type="link" text="Music" URL="http://opml.radiotime.com/Browse.ashx? c=Musik" key="music"/>
<outline type="link" text="Talk" URL="http://opml.radiotime.com/Browse.ashx? c=Talk" key="talk"/>
<outline type="link" text="Sports" URL="http://opml.radiotime.com/Browse.ashx? c=sports" key="sports"/>
<outline type="link" text=" By Location " URL="http://opml.radiotime.com/Browse.ashx? id=r0 " key="location"/>
<outline type="link" text="By Language" URL="http://opml.radiotime.com/Browse.ashx? c=lang" key="language"/>
<outline type="link" text="Podcasts" URL="http://opml.radiotime.com/Browse.ashx? c=podcast" key="podcast"/>
</body>
</opml>

Es ist nicht wirklich ein richtiger Filter, es war nur dummes Glück, dass ich das &c=local-Feld des Plugins gefunden habe, das nur den Ordner "Local Channels" in der ursprünglichen Root/Seed-Abfrage zurückgegeben hat, also wurde nur es aufgezählt, dann ist die "My Favorites"-Synchronisierung separat vom Aufzählungsteil des Skripts. Beachten Sie, dass die Verwendung von &c=- oder &r=-Werten im Plugin LatLon-Feld nicht auf Abfragen innerhalb der Aufzählungen funktioniert oder diese beeinflusst, da viele dieser Aufzählungsabfragen bereits einen c=- oder r=-Wert enthalten, so dass alles, was wir eingeben (das an das Ende der Abfragezeichenfolge angehängt ist) ignoriert wird und der andere Wert verwendet wird. Es schien nur diese erste Abfrage zu beeinflussen, bei der alle Ordner gefunden wurden, die aufgezählt werden sollen, wobei das Anhängen &c=lokal nur "Local Channels"-Ordner zurückgegeben wird.

Ich habe versucht, nach meinem LatLon-Wert die Nordamerika-Länder als Stamm der Aufzählung anzuhängen (für Nordamerika) zu verwenden und Ordner im Stammverzeichnis des TuneIn-Plugin-Ordners für jedes Land in Nordamerika erstellt und synchronisiert (sowie meine Favoriten danach). Keine Ordner für Musik, Talk, Sport, nach Standort, etc.

Im Folgenden finden Sie einige Samenwerte für wenn Sie es ausprobieren möchten. Beachten Sie, dass Sie weiter in andere Kontinente / Länder / Länder / Staaten / Provinzen / etc. mit zusätzlichen Lockenabfragen bohren können. Im Folgenden finden Sie heraus, wie ich Nordamerika id=r101218 gefunden habe.

C:\Users\REDACTED>curl -s -X GET "http://opml.radiotime.com/Browse.ashx? id= r0 "
<? xml version="1.0" encoding="UTF-8"? >
<opml version="1">
<Kopf>
<title> Nach Standort </title>
<status>200</status>

</head>
<body>
<outline type="link" text="Africa" URL="http://opml.radiotime.com/Browse.ashx? id=r101215" guide_id="r101215"/>
<outline type="link" text="Asia" URL="http://opml.radiotime.com/Browse.ashx? id=r101216" guide_id="r101216"/>
<outline type="link" text="Australasia" URL="http://opml.radiotime.com/Browse.ashx? id=r100297" guide_id="r100297"/>
<outline type="link" text="Central America" URL="http://opml.radiotime.com/Browse.ashx? id=r101320" guide_id="r101320"/>
<outline type="link" text="Europe" URL="http://opml.radiotime.com/Browse.ashx? id=r101217" guide_id="r101217"/>
<outline type="link" text=" North America " URL="http://opml.radiotime.com/Browse.ashx? id=r101218 " guide_id="r101218"/>
<outline type="link" text="South America" URL="http://opml.radiotime.com/Browse.ashx? id=r101219" guide_id="r101219"/>
</body>
</opml>
--------------------------------------------------------------------------------
C:\Users\REDACTED>curl -s -X GET "http://opml.radiotime.com/Browse.ashx? id=r101218 "
<? xml version="1.0" encoding="UTF-8"? >
<opml version="1">
<Kopf>
<title> Nordamerika </title>
<status>200</status>

</head>
<body>
<outline type="link" text="Bermuda" URL="http://opml.radiotime.com/Browse.ashx? id=r100306" guide_id="r100306"/>
<outline type="link" text="Canada" URL="http://opml.radiotime.com/Browse.ashx? id=r101227" guide_id="r101227"/>
<outline type="link" text="Caribbean Islands" URL="http://opml.radiotime.com/Browse.ashx? id=r101162" guide_id="r101162"/>
<outline type="link" text="Grönland" URL="http://opml.radiotime.com/Browse.ashx? id=r100348" guide_id="r100348"/>
<outline type="link" text="Mexico" URL="http://opml.radiotime.com/Browse.ashx? id=r101271" guide_id="r101271"/>
<sensart="link" text="St. Pierre-Miquelon" URL="http://opml.radiotime.com/Browse.ashx? id=r100419" guide_id="r100419"/>
<outline type="link" text="United States" URL="http://opml.radiotime.com/Browse.ashx? id=r100436" guide_id="r100436"/>
</body>
</opml>

Sorry... Ich verstehe, wie alles in der Theorie funktioniert, aber ich habe nicht die Programmierkenntnisse, um die Plugin-Schnittstelle anzupassen, um zusätzliche Funktionen hinzuzufügen, um das Plugin zu filtern / an bestimmte Abfragen anzupassen. Ich dachte so etwas wie Kontrollkästchen in der Schnittstelle, für die Container oder Kontinente, die das Skript einzeln aufzählen würde, anstatt der Aufzählung, die gerade an der Wurzel der Container beginnt und alles synchronisiert. Ein kompetenter Programmierer mag es leicht machen können, aber das ist jenseits meiner Fähigkeiten, ich muss mich vorerst einfach an meine "Anhängens an LatLon Field Workaround" halten! Und in aller Fairness gegenüber dem Plugin-Autor war es wahrscheinlich kein Problem, alles zu synchronisieren, bis die TuneIn-Server alle 3 Sekunden damit begannen, die Abfragen auf 1 zu beschränken. Ich denke, ich habe gesehen, dass das Plugin anfangs 50 Abfragen pro Sekunde durchgeführt hat, also synchronisieren wir 150x langsamer als früher synchronisiert (jetzt 3 Tage für eine vollständige Synchronisierung vs. 30 Minuten zuvor).

Okay, I'll give it a try.
It would be great if someone had the time and knowledge to optimize this plug-in.
I use it almost every day.
Thank you very much for your time and help.

[Sibasiach 2]

Worked perfectly, everything is there

All the windows that are useless to me are gone and are no longer synchronized (Talk, Sports, By Language, Podcasts).
And my favorites are back

“&id=r0” for By Location worked. 25h33min44sec. 

Without “&id=r0” over 3 days.

It would be nice if you could set the refresh interval in Emby to one month.

Thanks again.