JRiver tips and techniques: user experiences repository

[Paul R]

Neat little thing you can do...

 

If you are running JRemote with JRMC and you have a bluetooth enabled stereo system in your vehicle, you can play your entire library, streamed at CD quality, to your vehicle system.

 

Open port 52199 from the internet to your server. You do this in your firewall, and with some firewalls you can limit the access, always a good idea.

 

Setup a new "server" in JRemote, pointing to the outside address of your firewall. This is the address visible to your firewall.

 

Connect to your JRMC server

 

Set the output zone to "this device" and connect the device to your vehicle's stereo system.

 

Play away, anywhere, anytime, with CD quality and your full library available to you!

 

-Paul

 

*Caveat- you may incur network costs if you are not on an unlimited service plan.

 

*Caveat two - someone may try to access your server. In over six months of doing this, I have not seen anyone able to to break through and do any damage, but that is with my firewall. I think it is safe but YMMV!

[Paul R]

Ted..et all. Thanks so much for this thread..

Ted, I've never actually taken the JRiver leap.. Daft I know… I have trialled it, but it was so complicated I dropped it a while, then the trial ran out..LOL

 

Daft? Wap - do whatever it takes to get a device that can run JRemote, and trial JRiver again. Takes about - 10 mins to setup and let your music start importing, and JRemote makes using JRiver completely feasible and worth it.

 

As a side bonus, you get about the best DNLA server around, and when you get tired of messing with that fool DLNA stuff, it ain't hard to use multiple copies of JRMC around the place.

 

-Paul

[Paul R]

Playlists for Internet Radio.

 

I have most of my Internet Radio stations in a playlist I labeled "Internet Radio Stations." It works fine from the main machine playing to local zones, but has two little problems I am hoping some of you guru types (Hi Ted!) can help me with.

 

First, the playback won't stream from the main machine to remote zones. Everything else does, but not this. Is there a special setting or something I need to tweak?

 

Second, because of the first issue, I tried copying the playlists to a remote machine. No joy! I sure don't want to have find and reinsert a couple hundred radio station URLs again, and especially not if I want Internet radio on three or four remote systems used for streaming.

 

Any ideas or suggestions?

 

Thanks

-Paul

[Paul R]

Ah- that is what is not working. I was thinking that Playlists must have something special going on with them. Guess it is some kind of bug.

 

-Paul

 

 

Paul, I am not an internet radio guy, nor do I do much with playlists or zones, sorry.....but if you want to duplicate what you've done on one JRiver install to another, just backup the library and then use that library in the new install. File -> Library -> backup library. It creates a small library file that houses views, playlists, etc.

 

Also, go here and use the export playlist as MPL. That should work too. Simply import the mpl from the remote install.

Export Playlists - JRiverWiki

[Paul R]

If you are using JRMC to RIP the files, be sure you have the option checked to write the tags (and cover image) to the files. Elsewise, the metadata is only in the JRMC database, and won't show up on other machines unless you copy the database.

 

That's a lot of trouble for lazy people like me, so embedding the tags solves almost all those issues.

 

-Paul

 

Some very helpful info here. Thanks everyone!

 

Maybe this has already been covered, but here goes: I'm running MC19 on a Windows 7 computer and ripping CDs in AIFF format to a 2TB WD NAS. Everything is fine on this install of MC: file properties assign properly (artist, album, etc.) and album art.

 

Where the problem lies is on my second PC, a laptop running Vista and MC18 (was running MC19 but kept encountering "not responding" issues). I've tried everything I can think of but can't get file properties to display correctly. If I do a search the recently ripped albums will show up as unassigned and display the complete path but no artist, album, track name or number info.

 

I'd appreciate any assistance the brain trust on this forum can provide to help me resolve the issue.

[Paul R]

Hi Joe - I would use XLD (or dbPowerAmp) and write the files back into place, then refresh the JRMC database, but you can also do all the tagging stuff with JRMC itself.

 

Yours,

-Paul

 

Thanks, Paul, for the guidance. I will make sure to check this option. Didn't have the issue when using MC18 on my main computer. Must've occurred when I upgraded to 19. Now I just have to clean up the tags on the 20 or so CDs I ripped previously. Can you think of an efficient way to do this?

 

- Joe.

[Paul R]

Is it possible to shuffle between all songs as opposed to only shuffling per album? I don't see the ability to just show songs like iTunes can. Thanks

 

I think "Play Doctor" might offer you this capability. I am not where I can check it right now, but you might look into it.

 

Play Doctor - JRiverWiki

[Paul R]

That's not good!! :-(

 

Well, it isn't really bad either. On each platform, you can install as many copies as you like, so long as you own the equipment you install it upon. (Check the license agreement for details and restrictions.)

 

Even at at full price, JRMC is not expensive, especially considering what you get. And if you buy or upgrade early, it is even less so. About a week's worth of coffee break money.

 

Paul

[Paul R]

Power Question - How do you leave your JRMC server powered? On all the time? Or do you turn it off each evening?

 

CAPS owners - does your CAPS server remain on 24 hours a day? Does it get hot?

 

i thought this might count as a tip if there were good reasons for one way or the other. Thanks

 

All the music servers are on 24/7, and I usually leave the hard drives spinning as well. They do seem to last a lot longer that way, and anytime I want to access them for anything, they are immediately available. I calculate it costs me less than $100/year in power to do this, and that is easily recouped by the fewer breakdowns and such.

 

Windows machines get rebooted at least once a month, usually oftener. MacOS about every six months or when there is an OS upgrade that requires a reboot. Linux/Unix machines - at least once a year whether they need it or not. Just to remember how.

 

-Paul

[Paul R]

Matt and gang are second to none

 

For once, I totally agree with you.

 

It sometimes does take some encouragement to get them to believe that doing something is worthwhile (Mac version, memory play done correctly, etc.) but they always come through and do a great job. Even if they don't always believe that what they are being asked for will make a great deal of difference. (grin)

 

I like em a lot, and keep a current version of Windows, Mac, and Linux here.

 

-Paul

[Paul R]

Hi Paul,

 

It is intriguing how little they believe hardware makes a difference, but I was glad to see this function included. When memory playback is selected in JRMC, do you know how much it loads: album, song, # of songs?

 

In Amarra there is an option to choose, but I could not find it in JRMC.

 

Cheers

 

I think I knew at one time, but I have definitely slept since then, and that knowledge has long since slipped out of my memory. I *think* it preloads a certain number of tracks, but I am not sure. I know it does gapless playback without any issue. I think I remember from testing that it sure sounded a lot better to me.

 

Remember, a large percentage of their customers are not audiophiles, so the things that we hear and are important to us are of far less concern to a lot of their customers. What is really the mark of a good company is that they listen to we audiophiles and do try to address the issues that re important to us.

 

Of course, they hem and haw a bit, declaring that such and such could not possibly make a difference. But they do it anyway, and usually get it right on the first or second try.

 

Implementing memory play is a good example of that. Their first attempt was not very good, and I think they were more than a little surprised that Audiophiles could tell it wasn't up to snuff and complained about it. Their second attempt at memory play worked much better and garnered a lot of praise for the audiophile community. I think that surprised them almost as much, since they honestly did not believe it would make any audible difference. Now it works flawlessly, so far as I can tell.

 

Anyway, I expect that Matt or Jim will answer this for you in a day or two, as soon as they see the posting. You could ask on their Interact forum, but honestly, for Audiophile answers, I believe this is a better forum.

 

 

-Paul

[Paul R]

I have the pop when switching between tracks that are in different sample rates - but only over USB, not FW. So it apparently is either a driver or DAC issue, and not the software.

 

I think you can set it to play a bit of silence between tracks with different sample rates, which takes care of any DAC problems with pops and clicks and so forth. It doesn't hurt at all when you are playing albums, because the vast majority of the time, all the album tracks are at the same sample rate and bit depth.

 

-Paul

[Paul R]

Thanks for the details Sceptic.

 

Amarra is limited to just under 3GB of cache load and you do hear the benefit of stopped traffic from the HD in Amarra. Have not listened closely to JRiver yet, but I assume the impact is similar. Too bad it will not work with a NAS.

 

Don't like the idea of having another process running to decompress files loaded in memory though.

 

Whoa there- many many people, including me use memory play with files on a NAS and JRMC. Skeptic is incorrectly presenting this as an absolute problem. I am not even sure Skeptic's description is even accurate.

 

JRMC gives problems when ran on a skimpy processor, like old single threaded Atoms. Almost sny modern machine does not see these problems. Inuse an i5 based mavhine and have zero troubles.

 

Also if you are using some low quality components on your network, you are going to have problems.

 

And if you believe those folks that will spend $5k on a DAC but balk at any computer that costs more than $300, or insist that sone no-name wireless router is as good as an Airport Extreme, then you will most likely have troubles.

 

And like I said, the folks at J. River are accomodating to audiophiles like us, even though they do not always believe the changes and features we ask for make a difference.

 

Lastly, this insistance some of you guys have on limiting processes and such is a big issue to swallow. Processes do not usually take up any CPU cycles unless they have some work to do. I would rather see concentration kn getting software to native 64 status, which woukd eliminate any memory constraints that may still exist in 32 bit software.

[Paul R]

JRiver are the ones saying not to use it with a NAS, not me.

I explained the reason why they say this. It can work in some setups if your network connection is active and fast enough.

 

If you listen to a long track (say 20 minutes of classical music) and your network adapter (e.g. wireless card in a notebook) and NAS disks go to sleep, it might take longer than the 20 seconds or so JRiver give it to transfer and decode the next track. Depending on the hardware it might be significant and could even halt playback.

 

It is not hard to build home networks plenty fast enough to avoid this these days. This should not be an issue for anyone, and certainly not for anyone spending multi-thousands of dollars on audio equipment.

 

Not true with SACD if you aren't bitstreaming. Try a multichannel SACD or DFF track. (not DSF) [/Quote]

 

I only have a couple of DFFs, but they have no trouble at all streaming. No hiccups, stutters, or whatnot.

 

 

I'd rather see them use memory more efficiently so that would not be necessary. Store the track in RAM - or several - which is going to use less than a 1GB, instead of decoded audio which can be significantly larger.

 

A 580MB, 21 minute 6ch DFF becomes 7.4GB when you store it uncompressed.

This means the 1GB buffer has to be emptied and refilled eight times during playback, which requires significant CPU and disk/network access each time, instead of playing from a small buffer that results in a small but constant amount of CPU usage and no disk/network access.

Each time it does this, it interferes with anything else running on the computer, which did not happen before.

 

If you were to store the compressed tracks in memory, 1.6GB would store the entire album, resulting in zero disk/network access during playback. You would need 22GB with a 64-bit version of JRiver to store the album in memory uncompressed, and there would be 100% CPU usage and disk/network access for several minutes while it does this. [/Quote]

 

Well, believe it or not, we are saying something like the same thing here. You have to have a 64bit memory model to take advantage of more than about 3.6GB of RAM. With uncompressed audio files growing very large - well - one does need much more memory.

 

On the other hand, I am not convinced that totally decoding the file in a memory buffer is advisable.

 

It's a stupid design to placate people who either think they can hear the difference when their CPU is busy/idle or believe that lossless/uncompressed tracks sound different.

And even if you do believe that is true, the current system results in higher CPU and disk/network access than before.

 

It's worse in every single way, no matter what you believe about things like CPU usage during playback.[/QUote]

 

As I said, I think it is better than what they started with, and I believe I can hear a difference. That despite suspicions of exactly how they did it. (i.e. bumped up the buffer size, added a thread, etc. )

 

-Paul

[Paul R]

It is not speed, but latency that is the issue. If JRiver cached the next couple of tracks instead of only allowing 20s to transfer and decode the next track, it would not be an issue on anyone's setup.

Even with a fast network, hard drives in a NAS can be slow to spin up.

 

I don't think it's fair to assume that everyone running JRiver is spending thousands and thousands of dollars on gear either.

 

If they are worrying about the implementation of memory play, I suspect it is pretty safe to say they are an audiophile and have spent quite a chunk of change on their audio gear.

 

 

If JRiver is the only thing using your computer, it's probably fine.

If other applications are running and accessing the same disk/network (e.g. copying files) and the current track requires more than 1GB RAM, playback can be interrupted in the current system, or it can pause for several minutes between tracks.

 

If it is a music server, JRMC should well be about the only thing running on it. You can run other apps of course, but it is a compromise. The same is true of pretty much any other high end player as well, A+, HQPlayer, XXHigh End, etc.

 

Do you really think it's smart moving to 64-bit so that caching a full album would require 22GB of RAM when 1.6GB will do the same job?[/Quote]

 

If it did the same job, no. But it doesn't, and yes, it is smart to move up to 64bit processing now and be prepared to handle computers that routinely come with terabytes of memory. It isn't that far in the future.

 

 

With the current 32-bit app and its 1GB buffer, you could already keep three full tracks in memory at once, or more depending on the format, instead of having to refill the buffer 8x during playback of a single track.

 

It's not. Converting that same 580MB track to uncompressed WAV took two and a half minutes of 100% CPU usage on a fast quad-core i5, and required 3.9MB/s I/O.

 

If you believe that CPU usage and disk/network access affect playback quality, do you want the first two and a half minutes of a 21 minute track affected by this?

If you had a 64-bit version and decoded the full album into RAM, the entire first track would be played back with 100% CPU usage.[/Quote]

 

Only if you assume I am converting the album from DSD to PCM, which is something I just wouldn't do. I almost certainly would do the opposite though, and in fact, I do convert PCM to DSD for playback. If I really wanted to play it as PCM, I would convert it offline though.

 

I actually do rather agree with you though, both Windows and Unix based OS's already buffer all disk access into memory. That is very effective. To make the process more effective, you need to decode the data file into the format you are going to send to the DAC. There is little enough of that necessary with DSD, but a lot more of it necessary with PCM.

 

If it takes 150s of 100% CPU usage to decode the track as quickly as possible, that could be 21 minutes of 12% CPU usage instead, and only 0.46MB/s I/O.

With only 12% CPU usage, three of the CPU cores could sleep with only one being required for playback.[/Quote]

 

I honestly do not know where you are getting these numbers from- I can decode and re-encode a file much much faster than that, so I think your numbers are a bit off.

 

You also have to consider that many people use their computer for other tasks with music playing in the background, or want to play music to multiple rooms at once. If playing a single track eats up 100% of the CPU, there's nothing left for anything else.

 

That is why SACD tracks like this one which have to fill the buffer 8x over the course of 21 minutes is a serious problem, since it means that everything else on the PC is interrupted every few minutes, or other tasks on the PC can potentially interrupt playback in JRiver.

 

If you believe that you can hear a difference, do you hear an improvement?

Disk/network activity and CPU usage can be much higher during playback now.

 

With PCM formats this is a much smaller problem, since they are generally stereo, fit inside the 1GB buffer, and are a lot easier to decode compared to DST compression. [/Quote]

 

Well, yes and no. That PCM has to be decoded before it is buffered and sent to the DAC.

 

It would still be much more memory efficient to store compressed tracks rather than decompressing into memory, and this efficiency would allow you to store multiple tracks in advance, to greatly reduce disk/network access during playback, and the possibility of interruption.

 

If you mean send the compressed data over there network, I can see that. But it will still have to be decompressed and converted in memory anyway, I don't see a big deal about it. Even an 128kbs MP3 is actually decompressed into LPCM before being sent to the DAC. At least, in most cases.

 

The network queuing algorithm in JRMC is suboptimal, I will grant you that. It causes and is susceptible to packet queuing delays, which cause what you describe as latency. However, NAS that are not predictive and power down when they should not, networks too congested to reliably transfer traffic in a timely manner, and/or computers that are memory limited and depend upon weak processors are not something the J. River can be blamed for.

[Paul R]

First and foremost, the feature should prevent interruptions during playback.

Whether or not it improves audio quality should be a secondary concern.

 

Maybe to some, but that hardly flies with the Audiophiles - who tend to believe that audio quality trumps pretty much everything else. I don't agree with that, but there are a lot of people who do.

 

Since all lossless and uncompressed formats should sound the same, it should have no effect on quality.[/Quote]

Again, an unfounded assumption. All bit perfect players should sound the same too, but they rather obviously do not. Same with amplifiers, CD players, etc.

 

Few people own a computer solely dedicated to a single task. The strength of computers is that they can do many things.

I doubt JRiver would say that the program is intended to be the only program running on the computer.

 

The computer is always playing uncompressed audio from memory unless you are bitstreaming. The only difference is whether you decompress the whole thing at once with a lot of CPU usage, or do it in small chunks that consume an insignificant amount of CPU time during playback. So it is doing the same job.

 

Considering that the memory playback feature had audible glitches for several months with tracks that exceeded the 1GB buffer, and no-one on here seemed to notice, I don't think anyone would hear a difference between storing the tracks in their native format or uncompressed.

 

That was a long time ago, no memory player glitches in v18, v19, or v20, if memory serves me correctly. It just plays and plays.

 

It's amazing the things which people claim to hear on these forums, yet they somehow miss real problems like that.

 

I cannot understand why JRiver "caved in" and made this change, since their stance has generally been "bits are bits" and they still don't consider the memory playback option to be a quality feature. If it's not a quality feature, and it makes playback more susceptible to interruption (the opposite of every other program with this feature) when what exactly is it supposed to do, except inflate the amount of RAM the program consumes?

 

Well, you do have valid points here. I suspect they did it to please the audiophile segment of their market. The very *vocal* audiophile segment.

 

Personal computers have been limited to 32GB for years now, with many designs being limited to 16GB.

You're crazy to think that music playback needs anything like that amount of memory, or if you seriously believe that personal computers will be using 32x as much RAM in the near future.

 

Sez who? Mine certainly isn't, the music player machine (an Apple Mac Mini) is limited. But - go back to 1999 and try to convince *anyone* that a music server machine would need or could even make use of 16GB of RAM? That's only 15 years ago, not a very long time at all.

 

It's true that DDR4 is going to be increasing this limit with 16GB DIMMs, but that is not going to be cheap, and there are still no consumer platforms using it yet.

 

It will get cheap, like it always does. I remember paying hundred of dollars for 640k of RAM. Not even a megabyte...

 

 

JRiver uses a tiny amount of memory for music playback with the memory playback feature disabled.

 

Moving to 64-bit breaks a lot of features and compatibility. It will probably happen eventually but there is no need for it.

[/Quote]

 

Drivers breaking is always the fault of the driver writer. Both Windows and MacOS put out developer version of they OS's just so developers can avoid having the products break in new releases.

 

Do remember that even running JRMC on a 64 bit OS is a plus- as the OS will use all available memory to buffer disk access, providing exactly what you are asking for. In other words, turn memory play *off* in JRiver and you get exactly what you are asking for. Those who can and do hear a difference when memory play is on or off can choose whichever setting they prefer. To me, it makes a difference I can hear, so I use it. If they move to full 64 bit compatibility, it will probably be just in time for everything to break going to 256 bit addressing....

 

When you have a lot of hardware devices which all support different formats, some supporting native DSD and others not, it would double or triple the amount of disk space required if I did offline conversions for each device.

I use JRiver because it is supposed to be able to handle this.

 

Even if you are bitstreaming DSD, DST compression can use quite a bit of CPU power.

 

A 20+ minute, six-channel, DST-compressed SACD track? (all multichannel DSD should be DST compressed in its original SACD/DFF format)

 

Decoding PCM is trivial. Stereo 24/192 tracks use <0.1% CPU to decode on my computer.

There is essentially no difference in CPU usage between using memory playback or not with PCM. If anything it seemed to be slightly higher.

 

The only thing memory playback does for PCM is increase the amount of memory the program uses, and cause there to be higher CPU usage in the middle of a track if it doesn't fit into RAM when uncompressed.

 

Well, that's your opinion. Many people disagree.

 

If they stored the native format rather than uncompresed audio, and stored multiple tracks in RAM (you could fit half an album of high res FLAC into 1GB) then memory playback would be a useful feature for eliminating disk/network access during playback instead of a placebo or a detriment.

Exactly what you get with memory play turned *off*. Best of both worlds for you?

 

No, but it is something they can design against.

Which would you rather see, A or B?

 

1A) 1 track of 24/192 decoded into memory, taking up 700MB of RAM, using 0.1% CPU activity, with 20 seconds to buffer the next track.

1B) 4 tracks of 24/192 stored in its native format in memory, taking up 700MB of RAM, using 0.1% CPU activity, with no disk activity relating to the current track, and 10+ minutes to buffer the next track.

 

 

If more than 5% of program code is devoted to catching obscure errors, or 10% in total, then the program probably is poorly designed. At least, that has proven true in all my experience.

 

-Paul

[Paul R]

Well said? I have provided data to back up my post.

Everything else seems to be conjecture, and things suddenly went quiet on the subject once that data was posted.

 

Memory Playback in v18 is better in every way except for SACD ISO playback which is a case of "one step forward, two steps back".

 

+ Now stores tracks in memory (previously, tracks from ISOs were not stored in memory at all)

− Uses the new memory playback system

   − Wastes memory, and is only able to fit partial tracks in RAM now

   − No longer eliminates I/O during playback

   − Uses too much CPU, interrupting other processes on the system, or its own playback

 

Not exactly, more like everyone just got tired of arguing with you I think. Note again, you can have exactly what you want by turning off memory play - the OS will cache the uncompressed/unprocessed data in memory, giving you a slight bump at the start of a series of contiguous tracks, and little or no disk access while playing. This produces a different processing signature that you seem to prefer.

 

The end result is what sounds better for you. I can't hear any difference in playback on a Mac Mini with 4gb or a Mac Pro 6 core with 64GB of memory, using JRMC. Except the Pro makes a little bit more noise, and I cannot afford to dedicate it as a music server.

 

-Paul

[Paul R]

It is not about a "processing signature", it's about sensible resource usage.

And the OS does not cache the tracks in memory as you seem to assume - that's why the feature exists.

 

Nooo- the feature exists because Audiophiles asked for it and many think it sounds better.

 

All popular OS's cache disk access in memory, including Windows. Certainly MacOS, Linux, or any Unix derived OS will do that very very well.

 

-Paul

 

 

I just did a quick test, and in v18 I can play 18 channels of DSD at once (6 channel tracks to three locations) the memory usage peaked at about 600MB, and CPU usage was below 60% on average.

Other than the very start of each track, there was no disk access at all.

 

In v20 with Memory Playback enabled, trying to play a 6 channel DFF track in a single location results in CPU usage above 90%, disk access during playback, and memory usage over 1GB. The buffer is constantly emptied and refilled as a result of that.

When I tried playing to two locations (12 channels) it worked to begin with, but playback stuttered and eventually one of the zones just stopped playing anything.

 

 

So in v18 I can be playing to three different rooms at once and still be using the computer for other tasks at the same time.

 

In v20 I can't do anything else on the PC if Memory Playback is enabled, even if it's just playing to a single location.

And if the option is disabled, it's prone to interruption if another program is accessing the disk/network at the same time.

 

Things are definitely fine the way they are.

[Paul R]

It's supposed to use more memory to make playback far more difficult to interrupt.

That improves sound quality, since it prevents other processes on the computer interrupting playback. [/Quote]

 

I see that is what you think it does.

 

All lossless/uncompressed formats sound the same, so Memory Playback will have no impact on audio quality.[/Quote]

An unfounded and unsupported theory. There is plenty of evidence that different lossless and uncompressed formats can sound different. The explanations as to why that is possible range from common sense to utterly ridiculous, but just the same...

 

And if you believe that the decompression is causing lossless/uncompressed formats to sound different, the new Memory Playback has spikes of almost 100% CPU usage and disk/network access during playback, while the old Memory Playback was <25% CPU and had no disk/network access.

 

Not in the way that you're thinking. This is easy to test:

Play a track located on a portable drive.

Force eject the drive and remove it from the system.

 

Actually, yes, it works exactly the way I said. Testing here uncovered exactly the predicted behavior. As expected the track played through to completion and errored the next time it tried to access the disk. I say as expected, because that is totally out of J. River's provenance, unless they memory map files. And, I am only playing stereo tracks.

 

 

I'm sure that your response will be well that doesn't affect me, or to say that anyone using JRiver for playback should invest in faster disks/networking hardware and build a dedicated PC for music playback, but that is absurd. It's a software issue, not a hardware one, and something which was in a far better state before the changes they made in v19.

 

Not exactly, but expecting audiophile performance and consistency from a non-dedicated music server machine *is* absurd. You cannot have your cake and eat it too, at least not unless you are willing to compromise somewhere or another.

 

You can take a Mac Mini for $599 and have a dynamic and very good sounding little music server for no additional cost IRT the computer. You can spend incremental amounts and improve the sound time and time again. This is not speculation, not only myself, but countless other people do the exact same thing.

 

Whatever has managed to get your goat about JRMC is, I think, driving your opinion far more than fact.

 

-Paul

[Paul R]

You must be playing files which are small enough to fit inside the 1GB buffer even when decompressed then, since anything which does not has to access the disk several times during the track.

The issue is that you previously needed extremely long tracks to exceed the 1GB buffer, but with multichannel DSD it can now only store about 60 seconds of music until it has to access the disk again.

[/Quote]

 

There is no 1GB buffer limitation with the OS buffering, it will use all the memory available in a 64bit OS (save for the restrictions off consumer grade CPUs.) You can try running on MacOS or Linux to see this clearer, but Windows does buffer things up, which is why I suggested that even a 32bit application benefits from being ran on a 64bit or better OS.

 

Memory Playback in v18 makes playback 100% consistent and extremely difficult to interrupt in the middle of a track. (easy to interrupt gapless playback though)

 

v20 is very easy to interrupt during playback, and v20 itself interrupts other programs when memory playback is enabled since it has to frantically try and decompress the track as quickly as possible every 60 seconds to refill that buffer.

 

This is some artifact of your system, not a general thing that affects everyone.

 

The idea that you should need a dedicated PC for this task is ridiculous. Especially when v18 managed it just fine.

JRiver does so many things well. It's disappointing to see such a step backwards in performance and memory usage, and I'm surprised that anyone here would prefer a playback method which creates more CPU and disk activity during playback than before.

 

The only thing which needed to change was the way that gapless playback was handled and it would have been perfect.

 

Well, you state that like a fact, and it is anything but. Do you use your refrigerator to cool your home? How about using a lamp to heat a room?

 

What in the world makes you think a single computer should be the jack of all trades?

 

It can do so of course, but then, it will be the master of none, certainly not audio playback. With any OS or player software.

 

-Paul

[Paul R]

I just got an unpleasant private message from Skeptic (whomever he may be) telling me not to comment in this thread again because I do not have any idea what I am talking about. (amusement)

 

Audio is a hobby for me, but building computer OS's, real time software development, IT centers, and other similar activities has been my profession for more than 35 years. One I am judged sucessful at by my peers.

 

Skeptic is making a whole raft of bogus claims, anonymously, and with some obvious agenda. I don't care if people disagree with me, that is everyone's right, God Bless 'Em. But someone who is putting out bullshit and telling me to shut up because they are an expert- in my field - people like that can sit on a Pepsi bottle and spin like a top, IMNSHO.

 

-Paul

[Paul R]

BTW - You clearly poked too hard or managed to find a sensitive spot, in some circles you would have gotten a Bravo Zulu

 

Probably only in those groups that are familiar with what a Bravo Zulu is...

 

-Paul

[Paul R]

Hi dummy, thank you for the hint but this is the "hex editor" hack I wrote about, it won't prevent MC trying to start a browser.

 

Perhaps you should just consider using jPlay without JRMC? Or better yet, JRMC without jPlay at all? In either case, you would not have to deal with the pop up message alert.

 

-Paul

[Paul R]

Wow, why didn't I think of that? You've been very helpful, thank you mr. Raulerson.

 

Brilliant - you were able to take the hint about how inappropriate you messages are in this particular topic. Perfectly Brilliant!

[Paul R]

Currently I am experimenting with JRMC running as a server on on a ESX VM running on one of my servers. The only problem I have ran into is that VMWare disk access is pitifully slow, so I used direct Fibre passthrough connections to the SAN. I like this, though it does mean that music and video playback intrudes from the house "entertainment network" into my business network a little bit. Not much of course, but enough that there is a little voice in the back of my mind making me aware of it... "Entertainment network" computers most intrude into the business network only when they are backing up.

 

This VM is a Windows Server 2012 R2. I am thinking of trying a Windows 8.1, Linux, and MacOS Server as well. Since Server runs so much better in an ESX VM than any other Windows version, I am inclined to try it. Has anyone else tried running JRMC as a server only in a virtualized environment? Any tips or hints?

 

-Paul