I haven't changed any of the logic for device playback in a few weeks, so I would wager that it was the JRiver update that fixed your failing FLAC playback. I'm sorry to hear that there's still such a huge gap between sequential files - that certainly isn't acceptable. I'm not even sure what could be causing this. eos starts buffering the next track as soon as the current one begins playback. This is supposed to ensure that the two tracks playback gaplessly. You're the first person that has told me that this isn't working as expected, and I can't reproduce it on my end.
Can you tell me a little bit more about your setup? I run MC on both my HTPC and my (development) laptop.
It sounds like your problem is somehow related to bandwidth. I can't think of any reason why it would take ~90s for playback to start in any scenario. Does playback skip, or pause to buffer once started?
On your MC instance, click on "Services & Plug-ins" on the left, then "Media Network". Then, in the "Server" dropdown, click the option that's "{Name_of_Server} (Library Server)" (where {Name_of_Server} is the computer's name). This should filter the Activity log at the bottom so it's more manageable, and will show you all of the requests that your server is responding to from eos (or any other remotes). Then try playing back a FLAC file, and you'll see at least one GetFile call. Try typing the same URL into your device's browser, and see if you still experience the same delay trying to start playback.
So I'm back to the error message ~90% of the time. Occasionally it will play after a long (30s+) buffering status. My set up is running the MC Server on a Win 7 PC w/ i7, 16GB RAM, and internal 1TB storage (2x 500GB HDDs in RAID 0). I have a variety of Clients and Devices, but for testing, I have limited everything to just the server running and trying to get do not convert audio to work on an LG G2 running Android 4.4.2. I am connecting via WiFi on the local network and sitting right next to the router. As I mentioned, I can speed test 50Mbps up and down on my phone. Bandwidth is not the issue. I can stream 2hr 1080p 5.1 movies (down converted to 720p) on my phone without a blip.
When I paste the GetFile URL into by my browser, it immediately pops up with the Android message asking how I want to handle the file. If I select use Firefox (my Android browser), it downloads the GetFile file instantly. If I select to play it in Kodi, it pauses for a couple seconds to switch to the Kodi app, but then plays pretty much right away.
(Side note to JRiver -- Would it be possible to get cut/paste functionality out of that Service&Plug-Ins/Media Network area? Re-typing those URLs is brutal.)
Is it always the same image that doesn't load? Does it get stuck with the loading icon, or does it eventually load, or timeout and show the failure image? What if you have a list of around 10 images? Do other items past 4-5 still load?
If it's always the same image, you can try looking for the GetFile URL in the Media Network log I mentioned above, and try hitting the URL from the browser on your server. That'll tell you if it's a transcoding issue specific to that image.
In my re-testing, I could not get any images to not load anymore. Before it would hang on the loading icon for a while, and then switch to a triangled exclamation point icon when it couldn't load. It still hangs every once and a while, but will now load after 2-3 seconds. This is converting raw images to 1920x1080, and scrolling through rapidly, so I can understand the pause. I do think building a cache of the next 10-images as you view them would eliminate any pause what so ever though.
Thank you again for the work you have done on improving images. This is the functionality I had been hoping for in Gizmo forever.
It is currently possible to long press on an artist's name from the Playing Now page to be taken to a list of all of that artist's tracks. From there you could add all of those tracks to the Now Playing list, and perform a shuffle remaining on the playlist.
This is great. I didn't realize this functionality before. I did notice a couple issues though and one suggestion.
1. It does not like artist field lists (semi-colon separated in MC). It always returns "no results to display" even if there are other tracks with the exact same artists. Ideally, I would like it to display all the tracks by all the artists in the list. Interestingly, I tried the same action in Theater View because I thought it used to do it correctly, and it does nothing now either. I guess they changed it when people complained about clicking on the actor field list. That's a shame.
2. When you long press on the album name (or cover art for that matter), it appears to search for Album - Artist instead of Album - Album Artist (Auto) because on compilation albums, it only brings up the tracks on the album by that particular artist. So obviously, when the artist is a list, it gives you the "no results to display" message again. It would be nice to bring up tracks from the entire album, and this would solve the second part as well.
3. My suggestion: Would it be possible to add the same functionality to the track name field? So that it brought up all the tracks with the same name and artist when you have multiple versions of the same song?
Which brings me back to:
Tap actions? Not sure what you mean by that. Currently, long pressing on that cover art will perform a search for that album.
Yes, that is exactly what I mean. Since you can already long press on the album title, could we change long pressing on the album art and add more tap/swipe actions to the cover art in playing now?
For example:
Tap = Pause
Long Press = Stop
Swipe left = previous track
Swipe right = next track
Two finger left = rewind
Two finger right = fast forward
Swipe up = volume up
Swipe down = volume down
Two finger up = increase brightness
Two finger down = dim
Obviously, in portrait, this would change how swipe right goes to playlists, but there are buttons for that already. It would be nice to use tap/swipe actions for the more frequent tasks.
And one more tiny request -- I mix up the > and + symbols often. Would it be possible to change the confirmation message for added as next to play to "Added Next!"? Currently, they both say "Added!" and I'm not always sure if I added it to the queue correctly.
Excellent work on the video seeking by the way. It's working great.