Print

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

[tuneup]

Maybe once or twice in several hours of listening, I will get momentary dropouts of music lasting less than a second. Today it is happening every 5 - 10 minutes.

Are there any logs you can look at to see what is happening? Any things I can check on?

Music is stored on Synology DS214play with WD Red drives, JRiver is running on a new dedicated Dell laptop with no other programs running, except whatever may run in the background when you don't open a specific program, renderer is Bel Canto REFStream and JRemote is on an iPad Air.

Everything is hard-wired into the network, except for iPad on Wi=Fi. Network gigabit switches are Enterprise grade Pakedge.  

[JimH]

Are you running antivirus software?

[tuneup]

Yes Jim. Thanks. I will turn it off and only do a manual scan if the computer acts like it needs one.

[JimH]

If that doesn't work, uninstall it (to test).

Your AV program should not scan media files.  There is no reason.  It should not scan MC's library files.

We see lots of antivirus problems:
http://yabb.jriver.com/interact/index.php?topic=86096.msg588759#msg588759

[AndrewFG]

Your AV program should not scan media files.  There is no reason.  It should not scan MC's library files.

Jim,

I have been thinking about this.

When MC is playing to DLNA in transcoded format, it has to write its temporary transcoded output buffer file somewhere in Users/Appdata/Default/ (I don't recall the location exactly) before it can play the stream out via its HTTP server. And as I recall it the temporary output file has a file extension ".TMP" (or perhaps even it has no file extension at all). So it is not something completely indicative of being a media file type (not something that an A/V software could safely ignore), so it is my suspicion that it is this temporary file which often attracts the wrath of some people's A/V software. For example when you are transcoding to "L16 No Header" your temporary output file is not obviously a media file. So perhaps you guys should consider giving the temporary output file a bland file extension like ".MP3" / ".WAV" / ".WMV" to reassure the A/V into ignoring it (even if the output may not always really be in the format so stated).

Just an idea..

[tuneup]

Jim,

With AVG completely disabled, it is still sputtering and some outages are as long as 2 seconds, but it is happening a little less frequently than yesterday. It is still too often, about once every 5-10 minutes. I was about to install this system today, but my client fell ill and cancelled. Lucky for me. Before I uninstall AVG, I will switch back to my laptop and my iPad, as opposed to his. I do remember this happening with my gear, but far less often. I thought then that it was because my laptop was on wi-fi, as opposed to Ethernet. So this time I will test it wired. Will keep you posted.

[JimH]

If it is your AV causing the problem, disabling it may not be enough.  Uninstall to test.

The "Weird Problems" link in my signature might give you some ideas.

Is JRiver's Library (the database itself) stored locally?  It should be.

[JimH]

When MC is playing to DLNA in transcoded format, it has to write its temporary transcoded output buffer file somewhere in Users/Appdata/Default/ (I don't recall the location exactly) before it can play the stream out via its HTTP server. And as I recall it the temporary output file has a file extension ".TMP" (or perhaps even it has no file extension at all). So it is not something completely indicative of being a media file type (not something that an A/V software could safely ignore), so it is my suspicion that it is this temporary file which often attracts the wrath of some people's A/V software. For example when you are transcoding to "L16 No Header" your temporary output file is not obviously a media file. So perhaps you guys should consider giving the temporary output file a bland file extension like ".MP3" / ".WAV" / ".WMV" to reassure the A/V into ignoring it (even if the output may not always really be in the format so stated).

I think a strategy of trying to defend against antivirus software would probably not be effective and would not be a good use of our time.

An application developer should not be expected to solve the problems that AV software can cause.  The AV publishers are proposing to defend the user against malicious attacks, and that's the job they should be doing.  They should make sure they don't interfere with legitimate software.

[AndrewFG]

I think a strategy of trying to defend against antivirus software would probably not be effective and would not be a good use of our time.

An application developer should not be expected to solve the problems that AV software can cause.  The AV publishers are proposing to defend the user against malicious attacks, and that's the job they should be doing.  They should make sure they don't interfere with legitimate software.

High and mighty thoughts they are. (As Yoda would say). You get at least one A/V case a day. So you have to write at least on forum post a day. Changing the file extension on a temp transcoding buffer file seems like a worthwhile effort to me...

[JimH]

Then let me put in a lower fashion. I don't think it would work.  It would only fool the stupidest AV programs.

We have a lot of problems with other company's products.   OSX and driver problems, for example. Our priority must be to solve problems with our own software.