Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Haydnsimon]

I asked this a week or so ago but got zero replies. In many ways I think this is a major issue so I am going to ask again.

Is there anyway I can get JRiver to play music from a mapped cloud drive without buffering. I have my music collection stored in a Google drive which is mapped to drive Z on my windows computers using the free RAIDrive program. As befitting a serious collection these are lossless files. Try as I can I get less than satisfactory results when using JRiver for playback. Is there any way to solve this problem?

Shimon Crown

[Hendrik]

You can try using memory playback, specifically "Load full file (not decoded) into memory " (in Options -> Audio -> Settings). You'll still have pauses between tracks as the new track is being downloaded from the cloud, but it should not buffer within a track any longer.
If Media Center encounters something that looks like a local file but then happens to have very low access speed and high latency, because its actually on some cloud host, its not equipped to deal with that.

If you were to somehow access your files through HTTP or something like that, it would know to automatically buffer more.

[Spike1000]

Hendrik, could there be a setting to 'Enable extra (http style) buffering on high latency mapped drives'? The cloud isn't going away (just yet) and neither are mapped drives and drive letters as they are the lowest common denominator.

Spike

[Hendrik]

The entire purpose of tools like that is to actually hide the fact that its a cloud file from you. So no, Media Center just doesn't know where the file comes from.
The tool that does the mapping could actually solve that by itself by doing more aggressive buffering of files that are in the process of being requested, but since it doesn't work, it apparently doesn't.

Honestly I don't see such solutions to be ideal for live music playback without the tools that facilitate the mapping to actually fully assist the process in pre-caching/buffering files more aggressively. If you cannot offer low latency file access, then you need to pre-load/buffer a lot more, and if the tool hides the fact that its a cloud file, then it would be its job to do that.

Personally, I would not use cloud storage as the source of any playback. I would keep the music locally and use the cloud as a backup location for the music. But thats just me.

[Spike1000]

I can't disagree with any that but one of the issues is that mapping a drive to a cloud store is it's at the behest of the provided API or it's a hack/fudge. The cloud vendor doesn't want streamed or aggressive access as it consumes more of their resources and many of these cloud services are 'free' or on a business model where they want to give you as little of their resource as possible! I was just wondering if MC could 'ease the pain' for (cloud storage) situations users have no control over.

Spike

[Haydnsimon]

Thanks for the response.

Correct me if I am wrong but the bottom line is that JRiver MediaCenter isn't the right tool for this job  . I was going to suggest that this should be added but the way I see things the streaming services such as Tidal which offer high quality streaming are going to make personal music collections redundant anyway.

Shimon Crown

[Awesome Donkey]

but the way I see things the streaming services such as Tidal which offer high quality streaming are going to make personal music collections redundant anyway.

I don't agree with this. At least in my case, I'll never use a streaming service like Tidal to replace my personal music collection - I have stuff that Tidal doesn't even have in their catalog and likely never will.

That, and I don't think Tidal is here to stay for the long term. Tidal loses money every year so it's only a matter of time before they fold or another company like Apple buys them. Streaming services like this are pretty unreliable, they could be "here today, gone tomorrow". Same with using cloud storage for storing large music collections. Cloud storage providers could easily pull a Megaupload and suddenly discontinue/shutdown their services, then you'll lose your entire music collection unless you have a local backup. Though, granted, with larger services like Google's Drive and Microsoft's OneDrive this is not really likely to happen, you just never know.

Jim has a whole topic on this, following the issues with streaming services: https://yabb.jriver.com/interact/index.php/topic,101545.0.html

[Hendrik]

Correct me if I am wrong but the bottom line is that JRiver MediaCenter isn't the right tool for this job  .

The way I see it, it should be the job of the tool that maps the cloud storage to a local drive to ensure it offers the best performance possible. If an app starts accessing a file on cloud storage, the mapping tool could then download the full file and store it locally as long as its being used, and as such ensures that all future access is fast. This would be a trivial task for the mapping tool, because it absolutely knows where a file is from. MC does not know a file is from cloud storage, because all it sees is a local drive.

So in short, the mapping tool is perhaps not the tool for the job to ensure realtime media access. Unfortunately its website doesn't offer any information whatsoever about its options or behavior.

[trajanmcgill]

Is there anyway I can get JRiver to play music from a mapped cloud drive without buffering.

I'm imagining you don't really mean this-- you probably mean without lots of pauses to fill the buffer, right? Buffering (pre-loading a bunch of data into memory so that playback can be kept going smoothly even as the loading of the rest of the data varies in speed) is actually the solution to the problem it sounds like you are having. You probably want more of it, not less. I'd try someone else's suggestion of memory playback first; that is, buffering the entire file instead of just part of it. You may still get pauses between tracks as they load, but buffering pauses between tracks is better than in the middle of them.

Is there a reason you're using something other than the regular Google Drive app? That one actually synchronizes files from the local hard drive to the cloud, so instead of trying to load a file that is being streamed behind the scenes, you'd be loading a regular file from your local hard drive that just happens to be kept in sync via Google Drive. The drawback is that you need room to store all the files on the PC itself.

[RoderickGI]

I have my music collection stored in a Google drive which is mapped to drive Z on my windows computers using the free RAIDrive program.

Perhaps MC would work fine if you picked a different tool to map the drive letter. If you found a commercial tool and paid for it, then it might have the capability to manage the file downloads and appropriate buffering, so that you won't experience pauses during playback.

Did you look for other drive mapping tools?

This one claims to provide a "fast network drive" and has a free trial, so you can test it out. $50 for a single licence: https://www.expandrive.com/mount-google-drive-as-a-virtual-drive/

[RoderickGI]

I asked ExpanDrive about your issue, and learned something important. Here is my question and the answer:


On Thu, Nov 22, 2018 at 10:27 AM, "roderickgi"> wrote:
If I was to use ExpanDrive with Google Drive for storing and playing back large lossless music files, would ExpanDrive handle all the file buffering required to ensure continuous playback without pauses?

Hi,

ExpanDrive should handle that. However, we let you know that there are some rate API limitation when connecting to Google Drive set by Google. If you hit that limit - your speed goes down regardless of the quality of your connection and it dissolves within specific set of time set by Google.

If you plan to play huge files continuously it is better to Trial ExpanDrive before purchasing to make sure it meets your needs.

Thanks
--
Herman from ExpanDrive

So perhaps ExpanDrive could make playback work for you. It does use read-ahead buffering which may solve the playback problems. Or maybe Google Drive is the real problem, and deliberately so. In which case, it is Google Drive that isn't the correct tool for the job, rather than MC.

[Spike1000]

However, we let you know that there are some rate API limitation when connecting to Google Drive set by Google.

The Google API is pretty well documented.

https://developers.google.com/drive/api/v3/about-sdk

I don't believe I've (knowingly) hit that limit but my work with GDrive is typically in a different area.

Spike