Minimserver Displaying deleted genre

[Coolhand]

Adding back the albums one at a time seems like the right approach. When you find the problem album, please let me know which album it is and I will check the XML for this album in the trace log that you posted.

I have heard of control points having problems with rendering some album art images. There is no conclusive evidence yet that this the cause of the problem you're seeing.
[/quote]

Hi Simon,
thanks to suggestions from the developer of Yate who assessed a metatdata dump of a single track from the album which I suspected to be the only one with any obvious discrepancies, I found that the issue which was causing MinimServer to lock up was its inability to process or bypass the (Chinese ?) characters present in two fields.

Composer and Original Artist specify a 16 bit Unicode encoding but the actual data in the fields seems to be garbage.
Deleting these fields and reloading the album restored the correct loading all albums in the genre.

I have attached the metatdata txt. dump from one track of the album.

[simoncn]

(06-11-2014 14:52)Coolhand Wrote:  Hi Simon,
thanks to suggestions from the developer of Yate who assessed a metatdata dump of a single track from the album which I suspected to be the only one with any obvious discrepancies, I found that the issue which was causing MinimServer to lock up was its inability to process or bypass the (Chinese ?) characters present in two fields.

Composer and Original Artist specify a 16 bit Unicode encoding but the actual data in the fields seems to be garbage.
Deleting these fields and reloading the album restored the correct loading all albums in the genre.

I have attached the metatdata txt. dump from one track of the album.

Thanks for this information. From the trace log you sent earlier, this is the XML that MinimServer is sending for this album:

<container id="0$=Genre$189$albums$*a268" parentID="0$=Genre$189$albums" childCount="10" restricted="1" searchable="1">
<dc:title>Thriller</dc:title>
<upnp:genre>Reggae Dub</upnp:genre>
<upnp:artist role="AlbumArtist">Augustus Pablo</upnp:artist>
<upnp:artist role="Composer">㔂, 㟚퀀, 㟕敡牥, , ⠀攀, 㔀, , 㟤e汹</upnp:artist>
<upnp:artist>Augustus Pablo</upnp:artist>
<dc:creator>Augustus Pablo</dc:creator>
<upnp:albumArtURI dlna:profileID="JPEG_SM">http://10.0.1.6:9790/minimserver/*/Music/Augustus*20Pablo/Thriller/01*20Thriller.mp3/$!picture-235-89514.jpg</upnp:albumArtURI>
<upnp:class>object.container.album.musicAlbum</upnp:class>
</container>

As you can see, MinimServer is sending the garbage characters to the control point and the control point is choking on them.

I would be interested in investigating whether MinimServer could detect the problem and report and exclude the faulty file. For this, I would need the original copy of the file containing the garbage characters. Do you still have this?

[Coolhand]

(06-11-2014 16:33)simoncn Wrote:  

(06-11-2014 14:52)Coolhand Wrote:  Hi Simon,
thanks to suggestions from the developer of Yate who assessed a metatdata dump of a single track from the album which I suspected to be the only one with any obvious discrepancies, I found that the issue which was causing MinimServer to lock up was its inability to process or bypass the (Chinese ?) characters present in two fields.

Composer and Original Artist specify a 16 bit Unicode encoding but the actual data in the fields seems to be garbage.
Deleting these fields and reloading the album restored the correct loading all albums in the genre.

I have attached the metatdata txt. dump from one track of the album.

Thanks for this information. From the trace log you sent earlier, this is the XML that MinimServer is sending for this album:

<container id="0$=Genre$189$albums$*a268" parentID="0$=Genre$189$albums" childCount="10" restricted="1" searchable="1">
<dc:title>Thriller</dc:title>
<upnp:genre>Reggae Dub</upnp:genre>
<upnp:artist role="AlbumArtist">Augustus Pablo</upnp:artist>
<upnp:artist role="Composer">㔂, 㟚퀀, 㟕敡牥, , ⠀攀, 㔀, , 㟤e汹</upnp:artist>
<upnp:artist>Augustus Pablo</upnp:artist>
<dc:creator>Augustus Pablo</dc:creator>
<upnp:albumArtURI dlna:profileID="JPEG_SM">http://10.0.1.6:9790/minimserver/*/Music/Augustus*20Pablo/Thriller/01*20Thriller.mp3/$!picture-235-89514.jpg</upnp:albumArtURI>
<upnp:class>object.container.album.musicAlbum</upnp:class>
</container>

As you can see, MinimServer is sending the garbage characters to the control point and the control point is choking on them.

Aha.... very good then !
So the real issue is actually further down the line than it appeared.
I shall forward the relevant information to the developers of the control point in this case so that they may be able to also redress how they handle errant data.

I would be interested in investigating whether MinimServer could detect the problem and report and exclude the faulty file. For this, I would need the original copy of the file containing the garbage characters. Do you still have this?

I did keep a copy of the original album before processing out the garbage (as well as it other miscellaneous discrepant metadata).
So yes I can send it to you or a link to it.

[simoncn]

(06-11-2014 23:09)Coolhand Wrote:  I did keep a copy of the original album before processing out the garbage (as well as it other miscellaneous discrepant metadata).
So yes I can send it to you or a link to it.

Please upload the original file "01 Thriller.mp3" to my FTP server. I don't need any other files from the album. I will PM you the FTP server details. Thanks very much!

[simoncn]

(06-11-2014 16:33)simoncn Wrote:  I would be interested in investigating whether MinimServer could detect the problem and report and exclude the faulty file. For this, I would need the original copy of the file containing the garbage characters. Do you still have this?

This problem is caused by control characters (e.g., 0x02) appearing in some tag values. These characters are not legal in the XML data that the server sends to the control point and this is why the control point isn't handling this album correctly. The next release of MinimServer will check for these characters in tag values and ignore any such tag values (with a warning message).

Thanks very much for reporting this problem and helping me find out what caused it!

[Coolhand]

(08-11-2014 09:53)simoncn Wrote:  

(06-11-2014 16:33)simoncn Wrote:  I would be interested in investigating whether MinimServer could detect the problem and report and exclude the faulty file. For this, I would need the original copy of the file containing the garbage characters. Do you still have this?

This problem is caused by control characters (e.g., 0x02) appearing in some tag values. These characters are not legal in the XML data that the server sends to the control point and this is why the control point isn't handling this album correctly. The next release of MinimServer will check for these characters in tag values and ignore any such tag values (with a warning message).

Thanks very much for reporting this problem and helping me find out what caused it!

Great stuff Simon !
I'm just most grateful that you have been so willing to help resolve the issues which I have experienced, the least I can do is follow through with as detailed reports as I can offer from the perspective of a layman :-)

I've also relayed your technical feedback to both the developer of Yate and the MiND control point software so that each of you may have some further insights as to the causes of end user issues, and thus may be better equipped to resolve or prevent them from recurring in future iterations of your relevant software packages.

Thank you very kindly indeed