Is rtsp streams supported in linux client

Hi

Is rtsp streams in local video supported by the Linux Client player?

The roadmap for the client afaik doesn’t mention it here

If I add a local video with an rtsp command such as this

rtsp://login:password@192.168.1.1/defaultPrimary0?streamType=u

It produces an error relating to the @ symbol in the terminal windows visible in the background - the above being the usual way of passing login and password information in the rtsp command.

If I remove the login information so it’s just

rtsp://192.168.1.1/defaultPrimary0?streamType=u

once the layout downloads the client closes.

Any attempt to restart the client results in an immediate close without error message.
I have to reschedule a different layout and delete the .xlf files in the local library to regain control of the client.

I’ve mentioned this recovery procedure elsewhere in this forum - here

I’m using the latest cms 2.1.2 and I believe the latest linux player installed using snap and the player is using the linux display settings/profile in the cms.

Hopefully I’ve given enough information.

Thanks

Jeremy

Thank you for your message, RTSP streams should indeed work with the Linux Player.

I have been testing on my own Linux Player and was able to stream a test RTSP using the Local Video Widget. The stream URL is rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov n case you wish to try it yourself.

I’ve not tried passing credentials in an RTSP stream link so I cannot comment on whether this is an issue with the Linux Player, have you tried scheduling the Stream to a Xibo for Android Player to see if the same issue occurs when you try to use your stream?

Many Thanks.

Hi

Thanks for the update.

I’m just about to try your rtsp stream as a single widget full screen to see what happens.

My rtsp streams are live video cameras. I previously used a windows client and the vlc plugin to make these visible in the player, I’ve no android players unfortunately so unable to try that…I’m trying to get away from a windows client as the constant windows updates are now becoming a pain.

When adding a local rtsp stream widget this warning is visible in the cms if I scroll down which doesn’t mention Linux hence the query.

image

I’ll let you know how I get on. I’ve also just spotted that contrary to what I previously stated it’s picking up profile default rather than linux, so about to try again now I’ve sorted that too.

Hopefully I’ll get to the bottom of this.

Thanks again

Jeremy

Thank you for the heads up that you will give it a go, would be good to know if you encounter any issues with that test stream. I left mine running to see if any errors occur over time and so far the stream is working without issue.

I appreciate you mentioning about the note within the Local Video Widget and the fact it does not mention Linux. I will pass this onto the Development team.

Many Thanks.

Further to my previous message, I have been discussing this with the development team, the notes within the Local Video Widget will be updated to include Linux alongside Android and webOS. The documentation for the Module will also be updated.

Many Thanks.

Hi

I’m afraid to report that I’m having the same symptoms using a new layout with your suggested rtsp stream , xibo client never really starts - a terminal window opens I see the line with http://127.0.0.1:9696 appear and then it closes again - I don’t even get the xibo client splash screen.

Other things i’ve tried - running your suggested rtsp using vlc on the same client machine which incidentally is running Ubuntu 18.04.02 - I should have mentioned that earlier.

Does it possibly need something else installed that I may have missed to run rtsp streams from xibo?

I just need to sort out another problem that’s putting content into the syslog file, once i’ve sorted that I’ll be able to see if xibo is generating anything.

I’ll keep you updated.

Thanks again for your help/suggestions

Jeremy

No idea if this helps - this is being put in the syslog file when it closes.

image

Jeremy

Thank you for the feedback on this. I am using Ubuntu 18.04 as well but I am not encountering the same issue you are with RTSP streaming from that example link I provided.

I don’t remember installing anything else other than the latest updates when I installed Ubuntu, then I installed the Player. I decided to test the RTSP link again and I don’t have any issue with it displaying on my Player, it seems to open without issue as well.

Could you try removing the Layout from the schedule for that Player and making sure that the only layout scheduled is something simple, perhaps just text or an image. If you restart the Player, does it now open successfully?

Could you also provide screenshots of the Local Video Widget you have set up for the RTSP stream I passed on so I can see how you configured your layout?

Regarding the screenshot for the syslogs, I will pass this onto the development team for further investigation.

Many Thanks.

Hi

Just to clarify - layouts containing the following are all working fine. This is not an exhaustive list.
Static text, Local video uploaded to the library, embedded html, webpages, youtube videos, rss feeds.

The only layouts causing a problem that I’ve noticed so far are those containing a reference to a rtsp feed.

I’ve previously tried setting a layout containing a rtsp feed as the default layout, Once the client updates it closes with the error in syslog as above, if I restart the client it closes, again with the syslog error. I have to revert the default layout to something non rtsp related - delete the xlf file in the clients library and restart the client xibo player.

If I leave the default layout as something simple and schedule a layout contain an rtsp feed the client works up until the point that the layout is scheduled to kick in, the client closes, again logging that error to the syslog file, restarting the client causes it to close again. If i wait until after the time that the layout is scheduled for. i.e it’s back to a non rtsp default layout, when I then run the client it opens correctly. It’s not necessary for me to delete any .xlf files.

I have tried adding , removing and recreating various layouts with no change I’m afraid.
Here is the latest layout I’ve tried.

This is client info when showing a non rtsp layout - Not sure if the reference here to 22 files, is 22 still to download or 22 files that are currently needed.

When the client is running correctly the terminal window in the background is showing this.

the only other thing I’ve just noticed so about to check it. The background resolution for the layout above is 1024 x 768 - the client is saying my machine is 1280 x 1024 - so about to change that and see what the outcome is, in case it’s some sort of scaling issue.

I’m sure we’ll get to the bottom of this , thanks for your patience.

Jeremy

Hi

Just tried changing the resolution so the layout matches the resolution of the client and scheduled it to run from 22:00 - here is the screen dump of the client info just before 22:00 - at 22:00 the client closed with the same familiar syslog entry.

I’m out of ideas now I’m afraid. I’m also now out of the office until Tuesday so although further testing is possible remotely - it’s more likely to occur in the evenings.

Again thanks for your assistance.

Jeremy

Thank you for all of the information you have passed on about this, I will continue to try to replicate this issue you are seeing.

As far as I can see at this point the only differences I noticed are that I set a longer duration for the Widget, I do not use the xibo-player directory for my Library Location and I may be using a different version of the Xibo Player from you at the moment.

I would be interested to know if the performance is the same if you try the edge version of the Player. You will need to uninstall your current version of the Player and use the following command instead:

snap install xibo-player --channel=edge

Could you also choose an alternative location for your Local Library please? Perhaps the Documents folder as a test would be good instead of within the xibo-player directory.

I will wait to hear how the tests go.

Many Thanks.

Hi

Sorry for the delay - it seems I couldn’t test this remotely.

The edge version is working with your test stream - I’m about to try the cctv stream with this version.

Thanks

Jeremy

Hi

As part of the original process prior to reporting this problem I upgraded my CMS from 1.8.12 to 2.1.2 , it seems I’m now having a problem with layouts which may also have had an impact on this. However reverting to the original non edge client, reverts to the original crashing client problem.

I’ll log the cms issue as a seperate post/thread.

Hi

I’ve logged fresh call - Here relating to the CMS issue.

Also forgot to mention when using the original non edge client and changing the local library folder to a documents folder rather than within the program file structure, the client still crashed.

Jeremy

Please ignore mention above in relation to CMS problems, all due to my unfamiliarity of 2.1.2.

OK - so with my

rtsp://login:password@192.168.1.1/defaultPrimary0?streamType=u

Clients terminal window declares my layout invalid due to region invalid , region invalid is due to invalid media, and reason for that is given as Reason [URI] parse error:
And lists out my above command (rtsp://login:password@192.168.1.1/defaultPrimary0?streamType=u ) with the @ ? = replaced by their hex equivalents.
I’m guessing that this means some preprocessing of the command given for validity is failing rather than actually running my rtsp command and it failing.

Jeremy

I can confirm that it’s the second colon between the login and password that it’s objecting to. if I change this to something else, the layout is declared as valid. It then tries to use my provided link but then gives and [GstMediaPlayer] Error from elerment source: Could not open resources for reading and writing.

Seems i need to wait for someone to alter the coding to allow the above syntax when passing login credentials.

Apologies for the many posts.

Jeremy