HQPlayer + Muso

[jeremyb]

Looks like it might be tracks with embedded artwork that is tripping up hqp-control's --playlist-get query. So as it stands don't expect Muso to be able to provide Now Playing information for any tracks with embedded artwork (or any queued after such a track in the HQPlayer playlist). Watch this space though - have let Jussi know, hopefully he'll be able to make a fix soon.

[bibo01]

I have just tried. This time Now Playing worked fine with and without embedded artwork.

Somehow I do not get consistent results.

[bmoura]

Does Muso work with Windows 10?

[4est]

yes

Does Muso work with Windows 10?

[jeremyb]

I have just tried. This time Now Playing worked fine with and without embedded artwork.

Somehow I do not get consistent results.

 

Hmm, well it is definitely embedded artwork that makes it fail. Perhaps it is embedded artwork over a certain size, or of a particular source filetype. Certainly in my testing it's quite consistent in what files it fails on - and if I remove embedded artwork from those files it then works.

 

I'm working on a version which does not use hqp-control - I now understand how to communicate with HQPlayer's TCP socket with the XML protocol, and I know that the XML returned by the socket on a PlaylistGet is fine, it's hqp-control's processing of this information that fails when (certain) embedded artwork is returned.

[jeremyb]

Does Muso work with Windows 10?

 

I have no W10 environment (yet) to verify this on, so can't support any W10-specific issues officially yet - but yes it should just work.

[jeremyb]

Release News:

2.3.17

Tighter integration with HQPlayer via direct TCP socket rather than using hqp-control:

- should stop NP failure on certain embedded artwork in playlist

- more immediate status/timeline updates, without the need for a polling interval

- writes to hpq.log file in muso logs folder (on exit) to help diagnose any issues

 

This should hopefully be a major step forward in HQPlayer/Muso integration.

 

Thanks to Jussi for helping me understand HQPlayer's TCP socket XML protocol.

[bibo01]

A rather strange 1st experience.

 

I selected an album, playback OK, all tracks queued to HQPlayer. Now Playing is OK.

I stop, select another album, connection to HQPlayer is lost and nothing happens. I tried to reconnect with HQPlayer and resend tracks, but Muso freezes.

 

Restart Muso/HQPlayer. I cannot sent any track to HQPlayer. I click on Select, I can queue tracks but HQPlayer does not receive them.

Sometimes, instead, all tracks from an album are queued but only one is sent to HQPlayer.

Controls (stop, skip...) do not work.

Playback is unusually choppy.

In this version it seems that connection with HQPlayer is easily lost and it not possible to reconnect. General functions are unstable.

 

It's a Alpha version.

[jeremyb]

A rather strange 1st experience.

 

I selected an album, playback OK, all tracks queued to HQPlayer. Now Playing is OK.

I stop, select another album, connection to HQPlayer is lost and nothing happens. I tried to reconnect with HQPlayer and resend tracks, but Muso freezes.

 

Restart Muso/HQPlayer. I cannot sent any track to HQPlayer. I click on Select, I can queue tracks but HQPlayer does not receive them.

Sometimes, instead, all tracks from an album are queued but only one is sent to HQPlayer.

Controls (stop, skip...) do not work.

Playback is unusually choppy.

In this version it seems that connection with HQPlayer is easily lost and it not possible to reconnect. General functions are unstable.

 

It's a Alpha version.

 

Yes all this is still alpha - your experiences are at odds with mine, I found this very much more stable than using hqp-control. Please send me a hqp.log file for analysis, once you've experienced issues and closed Muso.

 

Are you using a RAMdisk or not?

[jeremyb]

Are you using a RAMdisk or not?

 

I think I may have a few issues like yours when NOT using a RAMdisk (or some other local folder as buffer folder) - so if you don't have one set up could you try it?

[bibo01]

I think I may have a few issues like yours when NOT using a RAMdisk (or some other local folder as buffer folder) - so if you don't have one set up could you try it?

Indeed, I am not using ramdisk.

[bibo01]

I think I may have a few issues like yours when NOT using a RAMdisk (or some other local folder as buffer folder) - so if you don't have one set up could you try it?

 

Indeed, I am not using ramdisk. I sent you HQPlayer.log with instructions.

[jeremyb]

Indeed, I am not using ramdisk. I sent you HQPlayer.log with instructions.

 

I think at least some of the issues may be down to the filepaths for remote files when being sent to HQPlayer - I see you use UNC paths. I'll do some more investigation.

[Miska]

I think at least some of the issues may be down to the filepaths for remote files when being sent to HQPlayer - I see you use UNC paths. I'll do some more investigation.

 

HQPlayer expects to get UTF-8 strings in XML (and returns the same). File paths should be non-prefixed, IOW, look like "C:\music\something" or "\\server\share\music\something". HQPlayer will handle necessary prefixing.

[jeremyb]

HQPlayer expects to get UTF-8 strings in XML (and returns the same). File paths should be non-prefixed, IOW, look like "C:\music\something" or "\\server\share\music\something". HQPlayer will handle necessary prefixing.

 

OK I see file paths come back in the get playlist prefixed with file:// - but this isn't presumably expected when adding files to a playlist. When Muso queues a collection of tracks it can send multiple UNC paths quite quickly in sequence (it doesn't build a .m3u playlist and queue that, for reasons I won't go into here but there is a good reason), and I'm finding in testing that only the first file is accepted. Is there a reason for that? Should I add a delay between socket sends?

[Miska]

OK I see file paths come back in the get playlist prefixed with file:// - but this isn't presumably expected when adding files to a playlist.

 

Playlist items are always URIs, you can also send the items as file: or http: URIs. But it can also recognize items that don't have the URI schema as local files. But what I meant is that the paths shouldn't have UNC prefixes (\\?\ etc).

 

When Muso queues a collection of tracks it can send multiple UNC paths quite quickly in sequence (it doesn't build a .m3u playlist and queue that, for reasons I won't go into here but there is a good reason), and I'm finding in testing that only the first file is accepted. Is there a reason for that? Should I add a delay between socket sends?

 

I don't see a reason why it wouldn't accept multiple, but it is best to wait for the command response before sending next command. You can do this by having internal list object from which you send items in your response handler until the list becomes empty. So the first item would be sent from the main code path and rest from the asynchronous response handler.

 

responseHandler (XmlDoc response)
{
   if (response.command == "PlaylistAdd" && response.result == "OK") sendNextItem();
}

[jeremyb]

OK guys I've added a hotfix to Muso 2.3.17 which should resolve a few of these comms issues hopefully. You won't get an alert it is available, but if you re-download from http://klarita.net/muso.html you should be able to install this new hotfix build (02) over your current 2.3.17 version.

[jeremyb]

OK guys I've added a hotfix to Muso 2.3.17 which should resolve a few of these comms issues hopefully. You won't get an alert it is available, but if you re-download from http://klarita.net/muso.html you should be able to install this new hotfix build (02) over your current 2.3.17 version.

 

Something's still up with the comms I think - sometimes it locks up completely. Investigating...

[jeremyb]

Something's still up with the comms I think - sometimes it locks up completely. Investigating...

 

Another hotfix done (build 03). Sorry to use you guys as alpha testers for this integration.

[bibo01]

Another hotfix done (build 03). Sorry to use you guys as alpha testers for this integration.

 

Not much better results than before.

Select an album to play, tracks are queued, only 3 tracks are sent to HQPlayer playlist, playback never begins.

Clear playlist, select a 2nd album, tracks are queued, no tracks to HQPlayer.

[jeremyb]

Back to the drawing board...

[jeremyb]

There's a build 05 up now - see if that fares any better

[bibo01]

There's a build 05 up now - see if that fares any better

It looks much better

Played many album with no problem. I passed from to the other one with no stopping and every time was OK.

I restarted Muso/HQPlayer and it was again OK.

I restarted Muso only and it was able to connect with HQPlayer fine.

Now Playing was OK.

Furthermore, I noticed that even when I drag'n'drop an album in HQPlayer and start playback from there, Now Playing was displaying the track. Indeed, Muso's commands would work under these conditions too.

[jeremyb]

It looks much better

Played many album with no problem. I passed from to the other one with no stopping and every time was OK.

I restarted Muso/HQPlayer and it was again OK.

I restarted Muso only and it was able to connect with HQPlayer fine.

Now Playing was OK.

Furthermore, I noticed that even when I drag'n'drop an album in HQPlayer and start playback from there, Now Playing was displaying the track. Indeed, Muso's commands would work under these conditions too.

 

Excellent - thanks.

 

There's a bit more robustness testing around edge cases to be done (eg. if you keep Muso open and stop/restart HQPlayer, recovery from internal socket/reader/writer disconnect, etc), but at least I have a basic architecture now which seems to work with a direct socket connection (which is proper inter-process integration in a way that using hqp-control wasn't).

[bibo01]

Good. Thanks

Just to remind you that I have not used ramdisk and remote. So I do not know how Muso behaves in those conditions.

Possibly next time I will try sending Muso's info over a lan to HQPlayer on a different PC.