Error is not received after trying to play an "unsupported' song on Netcast TV
softvision-teodorabadea opened this issue · comments
I have in our app a list of songs, when I try to play a song that seems to be unsupported it enters in the callback for successful playing, even thought the song did not start on the TV.
It would be really helpful to have an indication if the song actually starts or not in order to indicate it correctly in the app.
If needed I can provide the song for easy testing.
@softvision-teodorabadea, I tried playing a few ogg files on Netcast TVs, which are apparently unsupported, and errors are returned to the app.
Yes, please provide the song, and also the TV model you are using.
Hi,
Thank you for your quick response. I uploaded at the following location https://www.dropbox.com/sh/ary304hz3ou5k9f/AABCpzxSG1bprmgBs6PY2VN1a?dl=0 a picture with the information about TV model, firmware, etc.
Additionally I uploaded two songs, which make the issue reproduce on my side consistently. I first play successfully "17. Puya - Vestu salbatic [www.ten28.com].mp3" which correctly starts on the TV. After it startes playing I tap "02. Alb Negru feat. Ralflo & Rares - Zile [www.ten28.com].mp3", the "unsupported" song. I receive the callback of success, but on TV the previous song continues playing.
Additional note, before each song I also perform on Netcast TV a:
- (void) closeMedia:(LaunchSession *)launchSession success:(SuccessBlock)success failure:(FailureBlock)failure;
One issue found so far: if mediaInfo.title or other properties (such as URL) contain special XML chars, they are not properly escaped, so the TV returns an error and doesn't play the second song. The invalid XML is built here: https://github.com/ConnectSDK/Connect-SDK-iOS-Core/blob/38a3f16d0aac1672df8cf506aa09259a27a8dfad/Services/DLNAService.m#L985
The issue is with the general DLNA implementation. Two options to fix:
0. Encode all the user's strings (NB: strings in <CurrentURIMetaData> must be encoded twice!)
- Use a proper XML writer to build the strings – will slow down the implementation.
Either way, tests should cover the fix.
The XML escaping has been fixed in https://github.com/eunikolsky/Connect-SDK-iOS-Core/tree/bugfix/138_dlna_xml_encoding and will be merged in dev soon.
Back to the main issue, our Netcast TV behaves strangely when switching songs. Eg, I play song 1, switch to song 2 (works fine), then switch to song 1 – we send the SetAVTransportURI request, the TV doesn't reply anything for 20 seconds, then the Play request fails with an error. This scenario works on newer WebOS TVs via DLNA. So the issue may be with the old Netcast TVs or our DLNA implementation.
Turns out that for old Netcast TVs the app needs to close the LaunchSession of the first media, wait for a response (the success block), and then play another media. It works fine this way on two Netcast TVs I've tested.
The DLNA fix is merged into dev: da70954
@softvision-teodorabadea, please check out the latest code from the dev branch, and try with your Netcast TV. Make sure you call -[MediaPlayer closeMedia:success:failure:] on the current song, then play another one once it's done (in the success block) – that is required by those old TVs.
Thank you, I will give it a try.
The fix is available in the latest release: https://github.com/ConnectSDK/Connect-SDK-iOS/tree/1.4.3.
Closing this issue. @softvision-teodorabadea, please reopen if you encounter this issue again.