>implying that Linux player not locking file = none do on any OS, From: Jplay - just another scam? Topic ID: 92856 Options

[bred]

jplay pre-loads complete playlist into RAM guaranteeing zero disk I/O during music reproduction.
Maximal Priority Scheduling......

?

Is there any veracity to such claims? Knowing what little I know about computer audio (which is not all that much, despite having put together my own audio server with all the necessary hard and software) I really doubt there is any substance to the assertions. The only benefit I can see is to the developer charging something like 99$.....

Try a little experiment.

Copy an audio file in a tmp directory.
Open and play this file with your favourite player (vlc, mplayer, media player, foobar2000 ....)
And ... cancel the file (don't move in the trash but cancel it from the disk!!!)

What's happen ?
Normally the player continue to play without any problem.

This post has been edited by bred: Feb 15 2012, 14:15

[hlloyge]

What?
You can't delete file if it is locked by software which is accessing it.

This post has been edited by db1989: Feb 16 2012, 12:05

Reason for edit: removing unnecessary quote of above post

[bred]

I've tested mplayer under Linux and the file is not locked.
Also with mediaplayer under win you should move the file in the trash while mediaplayer is playing.

In every case it seems that all players pre load in RAM the current track.

This post has been edited by db1989: Feb 16 2012, 12:05

Reason for edit: as above

[hlloyge]

Nonsense. I've just tested WMP and Foobar2000 under Windows 7 - although I knew the result: both players lock the file they are playing, and you can't delete it.
I don't use any Linux on desktop, so I can't test it, but I think players also lock files when playing.

[icstm]

Nonsense. I've just tested WMP and Foobar2000 under Windows 7 - although I knew the result: both players lock the file they are playing, and you can't delete it.
I don't use any Linux on desktop, so I can't test it, but I think players also lock files when playing.

you are probably right, but to test what bred was saying. Put the file on a USB stick, play the file and pull the stick out...

[ojdo]

Put the file on a USB stick, play the file and pull the stick out...

You cannot do that, the player will lock the stick..

[hugson]

Nonsense. I've just tested WMP and Foobar2000 under Windows 7 - although I knew the result: both players lock the file they are playing, and you can't delete it.
I don't use any Linux on desktop, so I can't test it, but I think players also lock files when playing.

As far as Foobar and jRiver (and probably all other media players under Windows) are concerned, hiloyge is of course quite right. But jPlay does things differently, and there's no problem in deleting the disk file(s) of the track(s) that are playing.

[phofman]

I've tested mplayer under Linux and the file is not locked.

Of course it is not locked. Unix in general does not lock open files, unlike windows. The file is actually removed, after all open file descriptors are closed.

[andy o]

Why does this matter though? HDD access is hardly one of the top reasons of getting glitches. Almost never happens. It happens to me way more often with 100% CPU usage or DPC latencies, and the latter is most commonly caused by bad drivers IME.

This post has been edited by andy o: Feb 16 2012, 17:17

[db1989]

1:

Open and play this file with your favourite player (vlc, mplayer, media player, foobar2000 ....)
And ... cancel the file (don't move in the trash but cancel it from the disk!!!)

2:

Also with mediaplayer under win you should move the file in the trash while mediaplayer is playing.

Does not compute

Setting aside your (initially undisclosed) choice to publicise the behaviour of one Linux player as being representative of all Windows players: Moving a file is not the same as deleting it. Your claim that all players load the track to RAM and thereby allow its (actual) deletion from the hard disk appears to be lacking in support.

If someone wants this reopened for discussion, they are welcome to it, but it just seems to have cluttered up this thread even further.

Also, hugson, feel free to respond to the many counterarguments from other users; or, if you do not want to, we can split off your part of the original thread as futile, too.

This post has been edited by db1989: Feb 16 2012, 23:18