Closed odziom91 closed 5 months ago
It looks like you are installing the ServiceApp. What did you set the media playback system to? Original, Exteplayer3, gstplayer? I assume it's on Exteplayer3. And that will be exactly the error.
The bouquet you linked looks okay so far. However, it uses different playback systems identified by "4097, 5002, 5003". In my opinion, this can only work if the media playback system in the ServiceApp is set to original.
The wrapper is chosen by using the keywords “streamlink, YT-DL, YT-DLP” and are not part of the actual URL. The keywords only signal to enigma which wrapper should be used.
This means that your last example via the console naturally outputs “Protocol not found”. You would have to remove the "YT-DLP://". However, you can't get to the URL that works for playback. This is exactly the task that streamlink or yt-dlp takes on.
I also just see that your box uses servicehisilicon. That would be another media playback system and the reason you installed the ServiceApp in the first place.
My tip: Set up a clean 7.4 image in multiboot. Uninstall the system plugin “servicehisilicon”. Then install the packages as you mentioned above and please leave out the ServiceApp for now. Afterwards you can import and test the bouquet from azman again.
@odziom91 An attempt was made to fix the problem with a media playback system other than the original in the ServiceApp.
https://github.com/oe-mirrors/serviceapp/commit/44eae7772569d48e0955a8fc819ae543e66a1223
It should be available with an image after May 11, 2024.
Please give us feedback.
@4l3x2k Thank you for answers. I apologize for the lack of response...
What did you set the media playback system to? Original, Exteplayer3, gstplayer? I assume it's on Exteplayer3.
Yes. Exteplayer3.
The wrapper is chosen by using the keywords “streamlink, YT-DL, YT-DLP” and are not part of the actual URL. The keywords only signal to enigma which wrapper should be used.
I understand that and agree, but I thought that it "should" works with all playback systems. If it is not - it is not a problem to leave it as "original".
I also just see that your box uses servicehisilicon. That would be another media playback system and the reason you installed the ServiceApp in the first place.
That's right. Unfortunately when I changed in ServiceApp to "original" it used "servicehisilicon" to playback DLP, streamlink, etc.. Unfortunately it is completly broken (streams were non stop buffering), so I've uninstalled it - without issues so far.
I've installed clean stable (7.3) image and checked all scenarios.
I don't know if the patch was applied in 7.3 image (27.05.2024), but if it is available here, unfortunately it is not helpful for me.
edit: btw. Is there any reason why "servicehisillicon" is applied for Pulse4K image, but in image for SF8008 doesn't?
You need 7.4 if you use ServiceApp and StreamlinkWrapper. There is no fix for 7.3
Okay. I've installed 7.4 beta image (26.05.2024) and it works on both setups - original and serviceapp with exteplayer3. Tested with YT-DLP and Streamlink wrappers. Thank you for support! :)
Hello, I'm really confused with "wrapper" plugins in OpenATV which are definitely not working at all. Please check info below for details. It is "similar" to bug here: https://github.com/openatv/enigma2/issues/3238 But for me - it doesn't work at all.
Describe the bug / Actual behaviour: I noticed that IPTV that any wrapper plugin (streamlink, yt-dlp, yt-download) do not work at all.
Expected behaviour: The channels using the wrappers should work.
Has this issue started to happen just recently? The problem persists on tested stable (7.3) and beta (7.4) versions of OpenATV.
To reproduce:
I tested this problem with AZMAN IPTV playlist which is available here: https://raw.githubusercontent.com/azman26/azmanIPTVsettings/main/userbouquet.iptv-pl-regionalne-yt-radio-azman.tv
On fresh instance of OpenATV it is required to install few things:
Examples of channels from the playlist, which are available 24/7:
Streamlink:
YT-DLP:
Note: For links which are using streamlink service replacing streamlink%3a// with http://127.0.0.1:8088/ is a workaround for this problem. So it looks like it is not a problem with service. YT-DL and YT-DLP streams are not possible to fix with workaround.
Screenshots None. Channel won't start with black screen.
Image/Box Model (please complete the following information):
Additional context Error which I've got when the channels starts:
When I put command directly via ssh I received "Protocol not found":