Turn on Data Logging, repeat the crash, send them the log file.I can't locate it at all, just saying when the crashing for me started.
Turn on Data Logging, repeat the crash, send them the log file.I can't locate it at all, just saying when the crashing for me started.
Do you not accept JRiver's position that nothing has happened in a long time that would (or even could) cause the core “sound quality” to change?but the temptation of updating that version because it might improve sound quality etc
I switched to Audivana because of the instability of JRiver.
The fact that it doesn't lock up and isn't bloated like JRiver is makes it worthwhile to me.I tried Audirvana for a while. Just don't see the allure tbh. It's so "modern UI" driven to the point of being too plain to do much of anything aside from running perhaps bit perfect audio.
On my pc Jriver is very unstable, crashes maybe once a day.
Has anybody experienced this? Should I look elsewhere for audiophile software?
The fact that it doesn't lock up and isn't bloated like JRiver is makes it worthwhile to me.
I do use Foobar at times. Its handling of file management is not as good as Audivana's in my experience. When I sit down to listen to music, I want to do just that, and let the software get out of the way.Fair enough. Though if you want ligher weight, Foobar would do you favors more in that direction, but I guess you want the product all handled for you I presume? Don't want to tinker with elements and such?
But isn't file management best left to the file system? This classic quote has never been more right than nowadays: Those who do not understand UNIX are condemned to reinvent it, poorly.I do use Foobar at times. Its handling of file management is not as good as Audivana's in my experience.
I meant just presenting them in a logical way in the UI and sorting them with multiple filters. No conspiracy to worry about here......But isn't file management best left to the file system? This classic quote has never been more right than nowadays: Those who do not understand UNIX are condemned to reinvent it, poorly.
It simply hammers the CPU, but RAM and Disks should be fine with no issues. But even that can be rectified with lowering the process affinity. I just think it possibly has something to do with that window that's used while analyzing is occurring. It auto scrolls and sadly doesn't allow a per-session scan categorization of completed scans vs not completed to be separated if you have scanned files already and are using the option to scan already scanned files.
Again, the issue seems to be long active times of nearly anything.. If I have large playlists constantly loading into memory (I only do per-song load into memory non decoded, as decoded was even less stable if you have DSP and are scrubbing or doing too much of anything like jumping tracks and such), the program will eventually shut down randomly if I am scrolling throughout the UI and doing other things on the computer. I am running 16GB's of RAM, 4790K voltage and frequency locked to 4.5Ghz, with task manager always running. There are no anomalies visually from the processing load ever really. I think it's just a combination of DSP, WASAPI, loading into memort, scrolling about in the menu's and such, that the program decides to choke up and just turn off suddenly in a split second if I an rebuilding thumbnails or such. Media Network is it's own issue. It will crash(the whole program) in less than 24 hours no matter what, at all. Play music or not, the server will not stay up. I understand if it has to shut down due to dynamic IP issues perhaps, but why would it have to shut down JRiver, that I don't get. (it also shares a "scan" window issue, where in the media server tab you will see all the pings of the network in real-time, and it's just a constantly feeding log that never ends, so it perhaps causes the program to eventually turn itself off, might have something to do with perhaps me having caching of all sorts turned off, like no pagefile being enabled).
I should do more investigating, but I'm just too lazy truth be told. And it's not too much of an issue given how great this program is. But I find myself wanting to stream more and more, so I'll probably try another computer just to see if the issue is with this one.
Got rid of roon for cpu/memory issues,running on amd ryzen 7 16 gig ram only minor hiccups every now and then.if you run task manager,task manager uses a lot of ram/cpu.i got 5tb of files in jriver but i don't analyze them,it take about 24/48 to build everything back up from scratch.It simply hammers the CPU, but RAM and Disks should be fine with no issues. But even that can be rectified with lowering the process affinity. I just think it possibly has something to do with that window that's used while analyzing is occurring. It auto scrolls and sadly doesn't allow a per-session scan categorization of completed scans vs not completed to be separated if you have scanned files already and are using the option to scan already scanned files.
Again, the issue seems to be long active times of nearly anything.. If I have large playlists constantly loading into memory (I only do per-song load into memory non decoded, as decoded was even less stable if you have DSP and are scrubbing or doing too much of anything like jumping tracks and such), the program will eventually shut down randomly if I am scrolling throughout the UI and doing other things on the computer. I am running 16GB's of RAM, 4790K voltage and frequency locked to 4.5Ghz, with task manager always running. There are no anomalies visually from the processing load ever really. I think it's just a combination of DSP, WASAPI, loading into memort, scrolling about in the menu's and such, that the program decides to choke up and just turn off suddenly in a split second if I an rebuilding thumbnails or such. Media Network is it's own issue. It will crash(the whole program) in less than 24 hours no matter what, at all. Play music or not, the server will not stay up. I understand if it has to shut down due to dynamic IP issues perhaps, but why would it have to shut down JRiver, that I don't get. (it also shares a "scan" window issue, where in the media server tab you will see all the pings of the network in real-time, and it's just a constantly feeding log that never ends, so it perhaps causes the program to eventually turn itself off, might have something to do with perhaps me having caching of all sorts turned off, like no pagefile being enabled).
I should do more investigating, but I'm just too lazy truth be told. And it's not too much of an issue given how great this program is. But I find myself wanting to stream more and more, so I'll probably try another computer just to see if the issue is with this one.
I've been using JRiver for 17 years. I just looked it up and have been though at least 3,142 releases.The fact that it doesn't lock up and isn't bloated like JRiver is makes it worthwhile to me.
Audirvana reads a user-configurable amount of a track into memory at the beginning of playback. It makes sense that it would use more memory, and possibly GPU. If this behavior is not what you want, by all means use another program.I've been using JRiver for 17 years. I just looked it up and have been though at least 3,142 releases.
Anyway, I decided to download and try Audirvana. I realize you are talking about features when you mean "bloated." However, I like efficient playback software. I started playback in JRiver of 2 separate audio streams to 2 zones to two separate audio devices and started playback of Audirvana to one playback device. Audirvana is using more CPU and 10x the memory of JRiver and is also utilizing my GPU which doesn't make much sense. JRiver is fully loading the decoded files into memory. Audirvana continued to use the GPU even after playback had stopped and it isn't even the active window. Regarding program size, Audirvana is 19.9 MB and JRiver is 24.4 MB.
View attachment 75557
That is one of the options on JRiver as well.Audirvana reads a user-configurable amount of a track into memory at the beginning of playback. It makes sense that it would use more memory, and possibly GPU. If this behavior is not what you want, by all means use another program.