JPLAY for iOS Is Now Available

Superb. It is working! 

1 hour ago, Marcin_gps said:

JPLAY 1.0.4 is available

- Fast indexing of media servers;

- Improved compatibility with some renderers;

- Multiple bug fixes and improvements;

You are making progress! 

Good news:  JPlay found my JRiver and Logitech Media Server DLNA servers.  It updated the JRiver library (albeit pretty slowly) without crashing the app at the conclusion. 

Bad news:  Still won't index LMS. It appears to scan by title, but crashes out at some point. (I wasn't watching the two times it crashed, so I don't know at what percentage the "Error" message appeared. I will try again and watch more closely tonight.)  Also, when "removing" the LMS server after the crash, the app froze and had to be closed and restarted. 

Suggestion:  It is very time-consuming to scan an entire large library today add two or three albums. It would be great if the user could choose directories to add.  I don't know if that even is possible when you work off a server library rather than that library's source file directories, but it would be great to avoid a full library scan whenever possible. 

Keep up the efforts. Thanks for keeping us in the loop. 

Tested LMS again.   Still indexes to 3% and then returns the message "Error." This is consistent with past behavior.  

Because it happens each time at about the same place in the scan, I wonder if there is a particular file that is causing issues.  

@Marcin_gps, if I have any requests for JPLAY it is to make it so the Qobuz "Purchased" files can be shown or not shown in the overall Library. 

In my case, how I use my Qobuz favorites is either to put music I want to listen to periodically, but not buy, or to listen to for purchase. I don't always end up buying the album from Qobuz, if for example I can find a better version elsewhere, but when I do I then delete that album from my "Favorites." What ends up happening in JPLAY is that I now have the local file and the Qobuz "purchased" version in the library right next to each other. Each time I buy an album from Qobuz, this happens again. I am sure there are some people who want that there, making it an option would be great. As it stands right now, I am unable to find a filter combination to eliminate them from the over all library view.

edit: This row here is a great example with the two purchased but not favorited Diana Krall albums on the left, and the two Local versions on the right.

 

version 1.0.4 works for me without crashes, thank you. If I could ask...
a) search by Label in Qobuz,
b) for local files in the info list of all metadata that I wrote there,
c) integration of the TuneIn web radio into the JPLAY app

8 hours ago, Mike Rubin said:

Tested LMS again.   Still indexes to 3% and then returns the message "Error." This is consistent with past behavior.

How many albums do you have in your local library?

Is the LMS library a full/identical copy of the Minimserver and JRiver one? Have you tried to load them, one or both?

Or is it the very same library on a nas seen by LMS, Minimserver and JRiver?

I tried with a subset (597 albums) of my whole library and the task always ends well … JPlay still not indexing it in JPlay/My Library but this is another known issue that will be solved soon

12 hours ago, Mike Rubin said:

You are making progress! 

 

Good news:  JPlay found my JRiver and Logitech Media Server DLNA servers.  It updated the JRiver library (albeit pretty slowly) without crashing the app at the conclusion. 

 

Bad news:  Still won't index LMS. It appears to scan by title, but crashes out at some point. (I wasn't watching the two times it crashed, so I don't know at what percentage the "Error" message appeared. I will try again and watch more closely tonight.)  Also, when "removing" the LMS server after the crash, the app froze and had to be closed and restarted. 

 

Suggestion:  It is very time-consuming to scan an entire large library today add two or three albums. It would be great if the user could choose directories to add.  I don't know if that even is possible when you work off a server library rather than that library's source file directories, but it would be great to avoid a full library scan whenever possible. 

 

Keep up the efforts. Thanks for keeping us in the loop. 

Yes, LMS still does not index properly yet. As I write yesterday, we will introduce a new sync method to libraries that does not support search or where search does not work as expected(which is the case of LMS). The fix should be available next week.

We know that add a few albums can be time-consuming right now. We are looking into a solution for that.

3 hours ago, AudioDoctor said:

@Marcin_gps, if I have any requests for JPLAY it is to make it so the Qobuz "Purchased" files can be shown or not shown in the overall Library. 

 

In my case, how I use my Qobuz favorites is either to put music I want to listen to periodically, but not buy, or to listen to for purchase. I don't always end up buying the album from Qobuz, if for example I can find a better version elsewhere, but when I do I then delete that album from my "Favorites." What ends up happening in JPLAY is that I now have the local file and the Qobuz "purchased" version in the library right next to each other. Each time I buy an album from Qobuz, this happens again. I am sure there are some people who want that there, making it an option would be great. As it stands right now, I am unable to find a filter combination to eliminate them from the over all library view.

 

edit: This row here is a great example with the two purchased but not favorited Diana Krall albums on the left, and the two Local versions on the right.

 

If I understood correctly, a filter where you can exclude your favorites or all your purchased albums/tracks is enough for your case, right?

3 hours ago, PavelDosko said:

version 1.0.4 works for me without crashes, thank you. If I could ask...
a) search by Label in Qobuz,
b) for local files in the info list of all metadata that I wrote there,
c) integration of the TuneIn web radio into the JPLAY app

a) Qobuz API does not support search by Label. So, at least for now, it will not be possible.

b) We pretend to display more metadata in future releases. But keep in mind that app does not have direct access to files, so the metadata will always be what the server return to us. 

c) We plan to support web radio. Right now we are working on improve current features and fix bugs, but after that support web radio, should be one of our priorities.

I must say that I am very very impressed with the app. 

For my use case where I only have Qobuz and Tidal and no longer any local content, it is really very very fast at retrieving a search.

I’m used to Lumin.app, which I have used for 10 years, and even though I no longer have a Lumin A1 I still used Lumin app with a Pi running BuppleUpnpServer and a Pi4 with my moode based player with LPS feeding i2s to a heavily modified Metrum Amethyst with LPS. That combination has been very successful for me, so much so that it replaced the A1.

Being owner of Jplay switch for some years, which also made audible change, I was very excited to install the JPLAY iOS app. It did not take long to determine that the sound is much much better!

Congratulations Marcin, you have a new Customer.

1 hour ago, Easterman said:

I must say that I am very very impressed with the app. 

For my use case where I only have Qobuz and Tidal and no longer any local content, it is really very very fast at retrieving a search.

 

I’m used to Lumin.app, which I have used for 10 years, and even though I no longer have a Lumin A1 I still used Lumin app with a Pi running BuppleUpnpServer and a Pi4 with my moode based player with LPS feeding i2s to a heavily modified Metrum Amethyst with LPS. That combination has been very successful for me, so much so that it replaced the A1.

Being owner of Jplay switch for some years, which also made audible change, I was very excited to install the JPLAY iOS app. It did not take long to determine that the sound is much much better!

Congratulations Marcin, you have a new Customer.

That's great to hear! Enjoy and spread the good word :) 

@PavelDosko

Although search by label is not possible, you can browse by label if you click on the label name. Not perfect, but quite usable:

Yes, I know, thank you

10 hours ago, mnuno10 said:

If I understood correctly, a filter where you can exclude your favorites or all your purchased albums/tracks is enough for your case, right?

 

Yes, being able to exclude the purchased albums would work for me.

Some more issues:

(1).  I have several hundred download mp3 albums from a site formerly known as Daytrotter.com. It posted thousands of "Daytrotter Sessions" for free download. Although the titles varied over its last years, for a long while they all were just named  "Daytrotter Session." I have retained that title in the metadata for most.  Some artists have more than one "Daytrotter Session," so, to keep those artists' several sessions separate from one another, I in those cases have added "(20xx)" after "Daytrotter Session," with "20xx" being the year the particular session was recorded.

Unfortunately, JPlay sees all of the undated Daytrotter Sessions as a single title comprised of hundreds of volumes.  Similarly, all of the "Daytrotter Session (20xx)" sessions by various artists are seen, by year, as a single multi-volume title.  These screenshots show what I am trying to describe.

Playing back these albums, they all display as artwork the single fanned album for the particular volume into which they are grouped, even though each session has its own artwork.  These albums are imported from JRiver, which has no problem displaying them separately and playing them back with their own specific artwork.

(2).  Many, many, many albums display with artwork that's just wrong.  Here are three examples:

All of these albums are connected to the right artwork in JRiver.

(3).  Maybe 5-10% of the albums have no artwork at all.  Here's an example:

All of these albums display properly in JRiver.  

I try to embed the artwork in the files themselves wherever possible, but, to be honest, I don't know exactly how JRiver handles artwork. Sometimes, I gather, it just caches images that attach in the JRiver screen displays rather than embed the art, yet other controller apps that use the same NAS directories always seem to display the artwork properly, leading me to believe that it is almost always embedded.

I have scanned the library a few times and these issues have persisted.

2 hours ago, Mike Rubin said:

Some more issues:

 

(1).  I have several hundred download mp3 albums from a site formerly known as Daytrotter.com. It posted thousands of "Daytrotter Sessions" for free download. Although the titles varied over its last years, for a long while they all were just named  "Daytrotter Session." I have retained that title in the metadata for most.  Some artists have more than one "Daytrotter Session," so, to keep those artists' several sessions separate from one another, I in those cases have added "(20xx)" after "Daytrotter Session," with "20xx" being the year the particular session was recorded.

 

Unfortunately, JPlay sees all of the undated Daytrotter Sessions as a single title comprised of hundreds of volumes.  Similarly, all of the "Daytrotter Session (20xx)" sessions by various artists are seen, by year, as a single multi-volume title.  These screenshots show what I am trying to describe.

 

 

Playing back these albums, they all display as artwork the single fanned album for the particular volume into which they are grouped, even though each session has its own artwork.  These albums are imported from JRiver, which has no problem displaying them separately and playing them back with their own specific artwork.

 

(2).  Many, many, many albums display with artwork that's just wrong.  Here are three examples:

 

All of these albums are connected to the right artwork in JRiver.

 

(3).  Maybe 5-10% of the albums have no artwork at all.  Here's an example:

 

 

All of these albums display properly in JRiver.  

 

I try to embed the artwork in the files themselves wherever possible, but, to be honest, I don't know exactly how JRiver handles artwork. Sometimes, I gather, it just caches images that attach in the JRiver screen displays rather than embed the art, yet other controller apps that use the same NAS directories always seem to display the artwork properly, leading me to believe that it is almost always embedded.

 

I have scanned the library a few times and these issues have persisted.

 

Almost all servers use different URLs for the same image, so each track's image in an album will have a different URL although the image is the same as the album. So what we do is, we use the image of the album for all the tracks in that album, this way the app does not have to request and cache lots of unnecessary images.

But that turns out to not work properly in every case.

We will fix it and use the image returned by the server for each track.

5 hours ago, mnuno10 said:

Almost all servers use different URLs for the same image, so each track's image in an album will have a different URL although the image is the same as the album. So what we do is, we use the image of the album for all the tracks in that album, this way the app does not have to request and cache lots of unnecessary images.

But that turns out to not work properly in every case.

We will fix it and use the image returned by the server for each track.

I don't wish to solve one problem by creating another. If a larger art cache slows the app, that also could be a problem.  

The inaccurate and missing album art seem to be a bigger functionality problem.  

I did a new, clean scan and much, but not nearly all, of the inaccurate art has been realigned, so maybe a clean scan is all that is necessary. However, there still is a lot of missing artwork.  

Here is a shot of a randomly selected screen in the Albums view.  The three albums on the lower right have inaccurate art and three albums have none at all.  

I will be adding new music this afternoon and will be doing an update scan afterwards. I will look closely at these albums in particular after the update scan completes, to see if the incremental changes cause further issues or cure the existing ones.

7 hours ago, Mike Rubin said:

try to embed the artwork in the files themselves wherever possible, but, to be honest, I don't know exactly how JRiver handles artwork. Sometimes, I gather, it just caches images that attach in the JRiver screen displays rather than embed the art

If you use the tag editor of JRiver, on the left at bottom of the window, JRiver will embed the image in the track, but JRiver can also look for an image in the album folder, in this case it will show that .jpg image for the whole album.

7 hours ago, Mike Rubin said:

1).  I have several hundred download mp3 albums from a site formerly known as Daytrotter.com. It posted thousands of "Daytrotter Sessions" for free download. Although the titles varied over its last years, for a long while they all were just named  "Daytrotter Session." I have retained that title in the metadata for most.  Some artists have more than one "Daytrotter Session," so, to keep those artists' several sessions separate from one another, I in those cases have added "(20xx)" after "Daytrotter Session," with "20xx" being the year the particular session was recorded.

 

Unfortunately, JPlay sees all of the undated Daytrotter Sessions as a single title comprised of hundreds of volumes.  Similarly, all of the "Daytrotter Session (20xx)" sessions by various artists are seen, by year, as a single multi-volume title.  These screenshots show what I am trying to describe.

It would be interesting to give some examples on:

• how those files are organized in the folder
• if there are .jpg images in the folders
• which metadata are in Album, Artist, AlbumArtist tags, and if disc#/track# are there
• how those albums/tracks/artwork are shown using JRiver itself and Minimserver/JPlay

20 minutes ago, Mike Rubin said:

I don't wish to solve one problem by creating another. If a larger art cache slows the app, that also could be a problem.  

 

The inaccurate and missing album art seem to be a bigger functionality problem.  

 

I did a new, clean scan and much, but not nearly all, of the inaccurate art has been realigned, so maybe a clean scan is all that is necessary. However, there still is a lot of missing artwork.  

 

Here is a shot of a randomly selected screen in the Albums view.  The three albums on the lower right have inaccurate art and three albums have none at all.  

 

I will be adding new music this afternoon and will be doing an update scan afterwards. I will look closely at these albums in particular after the update scan completes, to see if the incremental changes cause further issues or cure the existing ones.

 

It should not introduce any problem or slow down the app. It will download more images, but they are local, so it should not be a problem at all. 

One thing that will be confusing is when user taps a cover from a track row, it will open the album, but the image will not be the same as in the track row.

For the "missing images and not accurate images" issue:

Try the "Clear image cache" option from JPLAY settings. If the problem persists it should be a JRiver issue, because JPLAY app uses the images that JRiver returns to it.

5 minutes ago, stefano_mbp said:

If you use the tag editor of JRiver, on the left at bottom of the window, JRiver will embed the image in the track, but JRiver can also look for an image in the album folder, in this case it will show that .jpg image for the whole album.

It would be interesting to give some examples on:

• how those files are organized in the folder
• if there are .jpg images in the folders
• which metadata are in Album, Artist, AlbumArtist tags, and if disc#/track# are there
• how those albums/tracks/artwork are shown using JRiver itself and Minimserver/JPlay

Examples and comments.

How organized in the folder:

>>Here are shots of my file manager directory listings for two albums.

If there are .jpg images in the folders:

>>Never. For the sake of portability to various devices such as ipods, I always try to embed when the supplied file does not arrive with artwork supplied.

Metadata:

>>Metadata displayed in Tag fields on the left.  Track number always is present and Artist and Album Artist always is identical. I do NOT add a disc number to single disc albums.

JRiver and Minimserver displays:

>>JRiver and Minimserver displays in Album view:

32 minutes ago, mnuno10 said:

It should not introduce any problem or slow down the app. It will download more images, but they are local, so it should not be a problem at all. 

One thing that will be confusing is when user taps a cover from a track row, it will open the album, but the image will not be the same as in the track row.

For the "missing images and not accurate images" issue:

Try the "Clear image cache" option from JPLAY settings. If the problem persists it should be a JRiver issue, because JPLAY app uses the images that JRiver returns to it.

I should have tried clearing the cache before responding to @stefano_mbp.  It appears that has solved most of my problems.  Only a few albums appear to have missing art.  Here are the ten albums from the previous post. They now have correct artwork.

55 minutes ago, Mike Rubin said:

1 hour ago, mnuno10 said:

I should have tried clearing the cache before responding to

Thanks anyway, I suspected that you could have several AlbumArtist for each album and a mix of embedded images and .jpg images but it doesn’t seem the actual case.

27 minutes ago, stefano_mbp said:

Thanks anyway, I suspected that you could have several AlbumArtist for each album and a mix of embedded images and .jpg images but it doesn’t seem the actual case.

 

Agreed. 

Even after both clearing the cache and doing a complete library rescan, though, I continue to have missing art for albums that display perfectly in JRiver and Minimserver/Mconnect, which makes me wonder why JPlay doesn't display them the same way.

19 minutes ago, Mike Rubin said:

which makes me wonder why JPlay doesn't display them the same way.

… maybe the embedded images are too big? You could try to reduce the image size  500x500 pixel maximum) and embed it again, removing the old one … it’s just an idea but it could be

42 minutes ago, stefano_mbp said:

… maybe the embedded images are too big? You could try to reduce the image size  500x500 pixel maximum) and embed it again, removing the old one … it’s just an idea but it could be

I suspect that is not the issue.  Of the four albums without art in the screenshot above, one is at 200x200, another is at 500x447, one is 600x600, and one is 945x945.  JRiver says they all are embedded in the files.

14 hours ago, Mike Rubin said:

Agreed. 

 

Even after both clearing the cache and doing a complete library rescan, though, I continue to have missing art for albums that display perfectly in JRiver and Minimserver/Mconnect, which makes me wonder why JPlay doesn't display them the same way.

 

That's quite odd. Clean image cache should clean all images from cache. Can you enable logs, navigate to an album where image is not correct using "By Folder" section and send me the logs so I can check if anything is wrong.

Hi Everyone, I started a main JPLAY for iOS thread in the forum. Forum threads give us a little better usability compared to threads attached to front page articles. Don't ask me why, it's something I've been trying to get corrected for years. 

Anyway, here's the official JPLAY for iOS thread. 

On 1/4/2023 at 1:52 PM, mnuno10 said:

Yes, MConnect does not use subscriptions or in-app purchases, so they don't need to validate that user is allowed to use their app. Right now you need internet to start JPLAY app, but has I said we will look on a solution, so user can make a few app launchs without internet connection.  

 Any progress here, by chance?