Possible filenanme parsing problem.

For help and support with Universal Media Server
Forum rules
Please make sure you follow the Problem Reporting Guidelines before posting if you want a reply
freemansteve
Posts: 24
Joined: Tue Apr 19, 2022 10:12 pm

Possible filenanme parsing problem.

Post by freemansteve »

Hi, as per a question I posted here: viewtopic.php?p=47305#p47305 ,
I have some problems getting file to "enqueue" (but I can get them to play!) on my media server, A Cambridge Audio "Evo 75", which is a DLNA-enabled network streamer "all-in-one" unit.

The Evo is 100% happy with files served from Emby (or Serviio) on my PC, and with files served from my RAID/NAS which runs a Twonky server internally.
With UMS however, I have found that a simple and entirely legit filename change will affect whether the file can be queued or not on the Evo player. The Evo runs a version of GStreamer under a Linux port.

It comes to something quite simple (I think!)

This file will not enqueue:
01 - Lond.mp3

but the exact same file, with one character changed in the filename, will work fine:
01 -xLond.mp3 is fine!

Also, the string " - " [space, hyphen, space] WILL work, so long as the filename is 8 characters or fewer, so:
01 - Lon.mp3 works
and, for example
01 -London Calling.mp3 also works.

I am happy to report this to Cambridge Audio Support (they are excellent) if this is a bug in their code, but I would appreciate some details from you able how you parse files - I may otherwise get stuck in the middle between CA and UMS without some useful data!

I have attached log data for "working" and "not working", and UMS was restarted in all my tests, in hope this was the cleanest way to test.

This may also be useful, in case they show in the traces:
20-4E-F6-58-4D-53 192.168.0.120 Evo_75
FA-57-58-AB-79-2C 192.168.0.110 Ann_iPad [online but not in play]
DC-FB-02-DA-0C-35 192.168.0.108 RAID [Twonky embedded]
Windows 10 (64)
UMS 13.3.0

See MP3Tag image attached - N.B. APE tags are "MP3Gain"-related tags, and my other tests suggest they are not relevant to the issues.

Thanks
Steve
Attachments
Capture.JPG
Capture.JPG (117.11 KiB) Viewed 16992 times
[not working] ums_dbg_2023-04-26-11-01.zip
(186.72 KiB) Downloaded 4066 times
[working] ums_dbg_2023-04-26-10-59.zip
(169.12 KiB) Downloaded 4083 times
User avatar
mik_s
Moderator
Posts: 1115
Joined: Wed Aug 23, 2017 11:03 pm
Location: UK

Re: Possible filenanme parsing problem.

Post by mik_s »

Is it possible to get logs from Emby or serviio? If you can then I can compare whey they send to what UMS sends and hopefully see what is failing.

I'll go over the logs later as it is very late for me now.
Logs are important for us to help, Please follow This Link before asking for support. Just a forum cleaner, Will help if I can but no expert.
freemansteve
Posts: 24
Joined: Tue Apr 19, 2022 10:12 pm

Re: Possible filenanme parsing problem.

Post by freemansteve »

I could not see how to get serviio logs, but I did set Emby to get "debug" logs... Attached.

N.B. Emby points at the same folder containing the exact "01 - Lond.mp3" file that fails with UMS (well that is to say it won't enqueue on my media player with UMS, but it works fine with Emby)
Attachments
emby.zip
(121.39 KiB) Downloaded 4055 times
freemansteve
Posts: 24
Joined: Tue Apr 19, 2022 10:12 pm

Re: Possible filenanme parsing problem.

Post by freemansteve »

Got serviio debug-level logs..
(oddly, no logging setup in the console, you have to manually edit files!)
Attachments
serviio.zip
(9.1 KiB) Downloaded 4102 times
User avatar
mik_s
Moderator
Posts: 1115
Joined: Wed Aug 23, 2017 11:03 pm
Location: UK

Re: Possible filenanme parsing problem.

Post by mik_s »

I looked at your 2 logs from UMS but they were never played or browsed from your player so cannot see what is being sent to it.
On UMS side it detects and correctly shows the right information for both of them no matter what the file is called.

Code: Select all

Matched format MP3 to "C:\Users\Steve\Desktop\test\01 -xLond.mp3"
Adding audio from the database: Audio Codec: MP3, Bitrate: 320000, Channels: 2, Sample Frequency: 48000 Hz, Artist: The Clash, Album: London Calling, Track Name: 01:  London Calling, Year: 1979, Track: 1, Genre: Punk
Adding new child "01 -xLond.mp3" with class "RealFile"

Code: Select all

Matched format MP3 to "C:\Users\Steve\Desktop\test\01 - Lond.mp3"
Adding audio from the database: Audio Codec: MP3, Bitrate: 320000, Channels: 2, Sample Frequency: 48000 Hz, Artist: The Clash, Album: London Calling, Track Name: 01:  London Calling, Year: 1979, Track: 1, Genre: Punk
Adding new child "01 - Lond.mp3" with class "RealFile"
Could you redo those but try to play them on your renderer first while creating the logs.

I'm not familiar with the logs for the other programs but they are only logging basic information and not showing the communication with the renderer. See if they have a trace mode for logging.

I saw that both of those programs identify that file, only the Serviio one mentions it is playing but no other information.

Code: Select all

PlaybackEventsManager] Playback of media item 1 (01:  London Calling [01 - Lond.mp3]) has started at 0% on Identifier=192.168.0.120, Profile=Generic DLNA profile, Name=Evo 75
PlaybackEventsManager] Playback of media item 1 (01:  London Calling [01 - Lond.mp3]) has stopped at 100% on Identifier=192.168.0.120, Profile=Generic DLNA profile, Name=Evo 75
Logs are important for us to help, Please follow This Link before asking for support. Just a forum cleaner, Will help if I can but no expert.
freemansteve
Posts: 24
Joined: Tue Apr 19, 2022 10:12 pm

Re: Possible filenanme parsing problem.

Post by freemansteve »

Hi, thanks for taking the time to help me.

This time I have UMS trace logs, where the scanned library contains two files, identical in MP3 music content, but with changed filenames and the tags changed (title, track_no), to make it easier to see what is playing.

You can see the files in the pic from MP3Tag.

In my media player, I tried to queue the file "01 - Lond.mp3" (but which is shown as "01: London Calling" in my media player i/f).
That file failed to queue.

I then tried to queue the file "02 -xLond.mp3" (but which is shown as "02: London Calling" in my media player i/f).
That file queued and I could start playing it fine.

Going back to the first file ("01 - Lond"), instead of trying to queue the file, I tried the option of "play from here" and both files loaded and were playable! How weird!

It looks like my media player has a bug when trying to queue files that originate with the string " - " included, if the filename is >8 chars, so I think the best outcome I can hope for is to see if you can identify anything I can report to Cambridge Audio's support guys that may help them pin down their bug. It doesn't really explain why the the data that Evo media player gets served from the same files from Serviio, Emby and Twonky always just work - there must be something the Evo can't handle with DLNA info just from UMS.

Apologies if this is a lot of effort for you, and I realize I'm probably the only UMS user that has this problem, but it is academically interesting for me to learn a bit more about DLAN/UPnP and why the data from the same files is different somehow between servers! Call me OCD!

Thanks
Steve
Attachments
ums_dbg_2023-04-28-10-53.zip
(294.34 KiB) Downloaded 4105 times
Capture.JPG
Capture.JPG (92.56 KiB) Viewed 16956 times
User avatar
mik_s
Moderator
Posts: 1115
Joined: Wed Aug 23, 2017 11:03 pm
Location: UK

Re: Possible filenanme parsing problem.

Post by mik_s »

I had a quick look and one thing I noticed is your player is being identified as "Pigasus" which was a VR player that was added recently.
They both use the word "Android" in the user-agent string and the Pigasus.conf only matches that.

That player does not have any supported formats defined so everything is being transcoded. This may be part of the problem as it means even MP3s are being transcoded so some of the tags may not be sent.

I'll try and make a conf file for the Cambridge Audio. I found the manual that shows all the supported formats so should not be too hard to do.

I'll need to dig in deeper with the communications between UMS and your player to find out why the filename makes a difference.
I did compare 2 parts with each file and it seemed almost the same except the duration was different in one of them, this may have not been the main file and only a preview though.
Logs are important for us to help, Please follow This Link before asking for support. Just a forum cleaner, Will help if I can but no expert.
User avatar
mik_s
Moderator
Posts: 1115
Joined: Wed Aug 23, 2017 11:03 pm
Location: UK

Re: Possible filenanme parsing problem.

Post by mik_s »

Try using this conf, copy to "C:\Program Files (x86)\Universal Media Server\renderers"

There are no suitable icons for it so will show as a Yamaha-RXA2050 as I used that conf as a starting point.

I think it is possible to use a custom icon by putting its full path in the RendererIcon section in the conf so you could use this one I downloaded from their site and shrunk it.
I don't know the required dimensions but any smaller it was unrecognisable.
(Is it a coincidence that the music playing is the one you are using?)

Let me know if that changes anything and if not could you redo those logs using this conf, it will narrow down what to look for.
Attachments
Cambridge_Audio_Evo_7-small.png
Cambridge_Audio_Evo_7-small.png (73.97 KiB) Viewed 16935 times
CA-Evo 75.conf
(1.41 KiB) Downloaded 4113 times
Logs are important for us to help, Please follow This Link before asking for support. Just a forum cleaner, Will help if I can but no expert.
freemansteve
Posts: 24
Joined: Tue Apr 19, 2022 10:12 pm

Re: Possible filenanme parsing problem.

Post by freemansteve »

Awesome - thanks so much for the efforts!

Here's what I found so far (I will get logs later)....

1) Copied the Evo conf into to the renderer folder and started UMS.
2) As before, the old-setting console view showed the CA logo for the Evo at 192.168.0.120 (it's a fixed DHCP address) - see pic 1. This is what I have always seen on the console....
3) Started the CA "StreamMagic" app on my android phone (this is the control surface for queueing/playing/managing the Evo device at .120) and the Pigasus icon appeared (as before) in the console window with address 192.168.0.110 (confirmed as my Android phone). UMS appears in the list of servers on the stream magic phone app as usual.
4) Navigated the StreamMagic (SM) app to folder on my PC and tried to enqueue the "bad" file. It failed.
5) Removed the "pigasus.conf" file from UMS's renderer folder, having realized that UMS identifying my phone as pigasus was maybe not a weird artefact, and may in fact be important!
6) Restarted UMS (quit the whole app and restarted) and now the console shows a chromecast device at .110 (my phone) instead of pigasus - see pic2
7) And now the good bit: Navigated to the folder with the test files, and the "bad" file ("01 - Lond.mp3") enqueued perfectly!

Interim conclusion is that it's something to do with the SM app on my phone (@ .110) - when UMS thinks it's pigasus, I get the enqueue failure, but when UMS thinks it's a chromecast device (possibly just some default?) everything is fine (so far). I am not yet certain whether the mp3 file is being sent to my phone and relayed to the Evo unit, or if it is being sent by UMS directly to the Evo (@ .120) which I believe is what normally happens and no idea if the data gets transcoded or not. I'll play later today and let you know what I find.

Apart from getting more logs, are there any useful tests I should try? Should I remove (or disable) the chromecast.cfg file to see what happens?
Attachments
pic2.JPG
pic2.JPG (60.87 KiB) Viewed 16923 times
pic1.JPG
pic1.JPG (36.8 KiB) Viewed 16923 times
freemansteve
Posts: 24
Joined: Tue Apr 19, 2022 10:12 pm

Re: Possible filenanme parsing problem.

Post by freemansteve »

Should I have put the .png image of the Evo you attached somewhere in a UMS folder as well as the .cfg file?

I saw no image or mention of Yamaha-RXA2050 in all the tests above....

Also, yes, it is coincidence that the track in the CA .png image is the same track as I'm using as a test (I have been practising it on my guitar!)
Post Reply