New WebStreams Plugin

[gillmacca01 226]

Still getting same error when using a link from an iptv provider. This same link works fine in Emby's Live TV

[looking111 33]

I tested this out. Unfortunately, the update deleted all my streams. They're still visible in the frontend, but there are no longer any streams in the backend. Now I have to restore the VM backup and copy the links from there.

Has anyone else noticed this behavior? (Emby Version 4.9.5.0)

Edited June 17 by looking111

[griam01 14]

Mine worked fine after the update.  The streams are all working, but I am on beta version

[looking111 33]

I've now restored the backup and copied my stream links.

I was able to reproduce the problem every time. After the update of the plugin, and after restart of the emby-server-service, the entire configuration in the backend was deleted. Unfortunately, the plugin's log only contains these 3 lines:

2026-06-17 22:55:27.997 Info App: Loading Emby.WebStreams.Plugin, Version=4.9.1.39, Culture=neutral, PublicKeyToken=null from /var/lib/emby/plugins/Emby.WebStreams.Plugin.dll
2026-06-17 22:55:29.571 Info App: Starting entry point Emby.WebStreams.Plugin.WebStreamsPlugin
2026-06-17 22:55:29.613 Info App: Entry point completed: Emby.WebStreams.Plugin.WebStreamsPlugin. Duration: 0.0413947 seconds

Anyway, as soon as I add the first link again, the entire configuration in the front end is deleted- or rather, it’s repopulated. I’ll test this functionality in the field tomorrow  .

[Chillout 118]

Refresh bug?

Refreshing Stream Source will cause all the streams to be refreshed compared to only the new content. 

 

 

[horstepipe 428]

still missing an automated way to update the streams via planned tasks in Emby.

[looking111 33]

On 6/17/2026 at 11:36 PM, looking111 said:

Anyway, as soon as I add the first link again, the entire configuration in the front end is deleted- or rather, it’s repopulated. I’ll test this functionality in the field tomorrow  .

That behavior 

 is still the same.

[Chillout 118]

On 12/11/2025 at 2:43 PM, softworkz said:

@Chillout - it could be a mime-type issue.

When you load the m3u in a browser while having dev tools open (F12 = > network tab) - what's the content-type response header?

This has been fixed in latest update. Thanks

[softworkz 5269]

On 6/19/2026 at 2:17 PM, horstepipe said:

still missing an automated way to update the streams via planned tasks in Emby.

It's the "Refresh Internet Channels" task

[Chillout 118]

Is there a plan to add back the previous functionality to limiting refreshing internet channels to only new/added links?

Each refresh takes 10hrs to reprocess 500k+ links when only a handful are new.  I feel a little guilty of all the carbon emissions that are created with each refresh. 

 

[horstepipe 428]

Resuming still doesn’t work on current version 

[gillmacca01 226]

Sorry for the long post.

When mapping my provider's M3U playlist URL directly into the WebStreams plugin, the connection consistently times out or fails. Testing the raw URL stream reveals a mandatory 30-second delay from the exact moment the URL request is executed to the moment data actually begins downloading.

Technical Breakdown of the 30-Second Delay;

1. Server-Side Database Compilation (15–20 Seconds):

The provider link is not a static file sitting ready on a server; it is an active database query (get.php?username=...). When the WebStreams plugin calls the URL, the IPTV provider's server must authenticate the credentials, query its database, and compile hundreds of thousands of lines of live channels, VOD movies, and series paths into a massive raw text payload (approx. 400MB). This server-side compilation takes up the bulk of the initial wait time.

2. Stream Interception & Header Allocation (5–10 Seconds):

Because the stream returns a massive .php script payload rather than a static file extension (like .m3u), the plugin's underlying network stack must pause to parse the initial stream headers, verify the data payload type, and allocate memory buffers to handle a text file of this magnitude before it can safely begin processing the byte-by-byte data transfer.

Impact on the WebStreams Plugin (Why it Fails):

Because the plugin's default network timeout window is shorter than the 30 seconds the provider's server requires to assemble the database, the plugin drops the connection. It assumes the server is dead or unresponsive before the provider has even finished building the payload to send back.

Furthermore, any automatic background re-tries or header checks sent by the plugin while the server is compiling can trigger the provider's firewall filters, resulting in "Forbidden" or "Resource Changed" connection drops.

Technical Question for the Developer / Community:

Is there an existing configuration file or hidden setting where I can manually increase the network connection timeout limit (e.g., setting it to 45 or 60 seconds)? Alternatively, is there a way to force the plugin to ignore initial .php headers and wait out the server compilation phase before dropping the socket?

 

[uvmonger 0]

Hi. I'm using the latest version of this plugin and when I try and import my m3u playlist I get this error message: Error code: Out of Memory