[BUG] XC API & M3U causing issues after Auto Merge

[x434]

Hi,

So i came across NextPVR since i was looking for a solution that is capable of merging channels, so i gave it a try. Currently running on version 5.0.5.200518.

So basically I have two XC accounts with the same IPTV provider. The provider limits the connection of streams to 1 per set of credentials so 2 accounts equals 2 simultaneous streams.

I started off with using the "Import using XC" button and imported the two credentials but i quickly noticed a bug in the implementation. Explanation Below:

• Added first XC account and select 1 channel to test with. https://prnt.sc/smlu9c
  
• Added the second XC account with different credentials. https://prnt.sc/smlw80
  
• Upon using the "Auto Merge" button and checking the devices again both XC lists show the same credentials (The credentials used are from the list that has higher priority). IE: both show https://prnt.sc/smlu9c
  

So upon using the "Auto Merge" it is editing the XC configuration resulting in issues..

Due to this current issue i opted to import both m3u via by giving them the URL myself and downloaded the .m3u file to test with VLC via the /service?method=channel.m3u endpoint (Selected 10 channels on both playlists for tests and limited the "max-connections" to 1 on both) and merged the channels.

After rechecking the "devices" again it was noted that the same issue persisted ie, the credentials of the second playlist got replaced with the credentials with the higher priority..

My Goal was to use the generated M3U from NextPVR to be able to stream two separate streams but the above causes the oldest playing stream to timeout when more than 1 stream is open.

Also i would like to suggest adding a looped video displaying "No Streams available" or not returning a stream if all max-connections are already taken by someone else. Current implementation results in the new stream taking over the old one which i dont think is ideal since it results in stream disruptions. 

Can someone look into this showstopper? 

Let me know if i can help in any other way and the planned way forward.

Thanks and I appreciate the hard work done!

[mvallevand]

The channel.m3u endpoint wont resolve the issue that two instances of the /live interface needs a unique client identifier.

Martin.

[sub]

So basically I have two XC accounts with the same IPTV provider. The provider limits the connection of streams to 1 per set of credentials so 2 accounts equals 2 simultaneous streams.

I started off with using the "Import using XC" button and imported the two credentials but i quickly noticed a bug in the implementation. Explanation Below:

• Added first XC account and select 1 channel to test with. https://prnt.sc/smlu9c
  
• Added the second XC account with different credentials. https://prnt.sc/smlw80
  
• Upon using the "Auto Merge" button and checking the devices again both XC lists show the same credentials (The credentials used are from the list that has higher priority). IE: both show https://prnt.sc/smlu9c
  

So upon using the "Auto Merge" it is editing the XC configuration resulting in issues..

Actually, this is just cosmetic. The 'details' column just happens to be showing the mapping from the first source. It's not showing the mappings for the other sources of this channel.

I should probably modify it to say "(and 2 others)" or something like that when it has three mappings.

If you make schedule two recordings, then take a look at the device status, you'll see it successfully recording on each.

[sub]

As Martin indicated, when trying to watch as client like VLC using /service?method=channel.m3u, you need to be aware that they'll default to the session, so starting a second stream would stop the first one. Add "&client=1" and "&client=2", so "/service?method=channel.m3u&client=1" etc.

[x434]

Thanks for the clarification of the cosmetic bug and for letting me know i need to specify a different client as part of the URL.