MediaMonkey forum

Hi,
running MM version 5_0_3_2627 and accessing a DLNA server on the network implemented through miniDLNA running ofn a Raspberry Pi.
Looking at the logs of miniDLNA looks like there is some issue with the select statement - I read

(see the SQL statement on https://pastebin.com/jdzd9fRh I tried to paste it here but it's not allowed.

Is there any way to fix this issue?
Thanks

EDIT:
Sorry in the pastebin I forgot the miniDLNA messages.
here they are:

Hi,
That error is not MM one but MiniDLNA See https://github.com/keenetic/minidlna/bl ... upnpsoap.c

Are you sure that version you use supports DLNA search correctly?

You are not the only one, but search not found any current Solution.

I would suggest asking on their forum and also make sure you are using latest Beta from https://www.mediamonkey.com/forum/viewt ... 86639&sd=d

Thank you so much!
That helps a lot narrowing the issue. I'll go pestering the guys there then

However - I can observe that performing exactly the same search using another client, namely Bubble UPnP for Android, causes no errors in miniDLNA - so I'm not really sure it's the right diagnosis.

Appreciate your amazing support anyway.
Take care

REEDIT:
observing the SQL, there is indeed something weird to me. all fields are referenced using the table alias d for table DETAILS, except for author, referenced as upnp:author instead of d.author.
Not sure if this is correct.

Hi,
Not so sure. How Bubble UPnP for Android behaves when you try to access MM5 as DLNA server?

Asking if that differs or you may have problems it is possible to have DLNA standard issues that needs to be reviewed.

do you mean what happens when MM tries to access bubble UPnP DLNA server?
I shold see if there is a log of database in bubble UPnP DLNA server.

Just to reinforce my impression is an issue with MM, I tried with Hificast, and no errors logged in the miniDLNA database log.
Tried with Windows Media Player too. No errors there too.

So I really doubt this is a coincidence.

I guess it should not be difficult to understand if that upnp:artist thing is a slipup in programming or not.

edoli wrote: ↑Mon Aug 22, 2022 5:27 pm do you mean what happens when MM tries to access bubble UPnP DLNA server?

I meant bubble UPnP access MM5 DLNA server.

Can yo make screenshots in MM and create debug log as described here https://www.mediamonkey.com/forum/viewt ... 30&t=86643 while access miniDLNA?

OK,
misidentification by my side. sorry for this.
I understood that the error is originated by MM Android (currently using version 1.4.3.950) not by MM desktop (I am using both)
So it looks like the SQL statement is shaped differently if comes from MM android or desktop - definitely sound like a bug to me then.

I submitted an Android log, id DPHCECFKFI

Not sure if an admin can help relocating this bug to the Android section of the forum.
Thanks!

Hi,
Ok I moved it to Android Section.

Also I created https://www.ventismedia.com/mantis/view.php?id=19321 for us to analyze and check difference.

A question for you, are you saying that MM5 access miniDLNA?

Yes, I am using MM not as DLNA server, but to access a miniDLNA server on the network.
The problem is therefore with the sSL requests sent by MM to miniDLNA, not viceversa. Apologies if that was not clear from the beginning - the error is the error I read in the miniDLNA server log on Raspberry.

That is the reason it looked so odd to me you asked the log of MM DLNA server - none is running.

Hi,
that is exactly what I am talking about, MMA do not send SQL calls to miniDLNA it just sends standard Search message to DLNA server to return list of tracks for specific search.

It is standardized back in 2010 (Page. 249) See current standard at http://upnp.org/specs/av/UPnP-av-Conten ... ervice.pdf where on page 172 upnp:author is explained. d.author does not exist as it is internally made in miniDLNA. So bug is definitely in miniDLNA "sql.c:88/upnpsoap.c:123: warn: Returning UPnPError 708: Unsupported" where it doesn't support the standards listed in above document.

Also that is the reason why I asked you to test with MM5 DLNA server or in the matter any other DLNA server not miniDLNA. You said you use both MMA and MM5 for accessing and browsing miniDLNA so does it even asks for author listing?

EDIT: To confirm above miniDLNA really do not support handle "upnp:author" as clearly seen at https://github.com/keenetic/minidlna/bl ... upnpsoap.c from line 201-214 and 376-384 sorry, but answer for this should be comming from miniDLNA devs also because d.author also do not exist in DB structure (I think, as I am not miniDLNA dev and based on upnpsoap.c).

Ok, so it looks like MM desktop latest version can talk to miniDLNA and get itself understood well, while MM android version not and that should be accepted as not a bug. Got that.
Thanks.

Hi,
That is why bug is opened for analyze and correction, for me it looks like MM5 do not even query upnp:author and thus no issues? We will see what MMA logs will show.

I would like to add that after a year the current Android MM 2.0.0.1095 (pro) still cannot search neither minidlna nor another DLNA server like minimServer on Raspberry, and exactly the same "prepare failed: near ":author": syntax error" is displayed in the log.

With an extensive music selection on a server this hampers daily use quite a bit and reduces MM down to a non-intelligent "just play a preselected list or folder content" player

Hi,
When you get that error use ☰ -> ? -> Send logs and write log id here for reference so that we can see why MMA query fail.

Thanks for the feeback. Log ID AW9YZKPPSY was sent.