Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: >implying that Linux player not locking file = none do on any OS (Read 2943 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

>implying that Linux player not locking file = none do on any OS

Quote
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.

>implying that Linux player not locking file = none do on any OS

Reply #1
What?
You can't delete file if it is locked by software which is accessing it.
Error 404; signature server not available.

>implying that Linux player not locking file = none do on any OS

Reply #2
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.

>implying that Linux player not locking file = none do on any OS

Reply #3
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.
Error 404; signature server not available.

>implying that Linux player not locking file = none do on any OS

Reply #4
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... 

>implying that Linux player not locking file = none do on any OS

Reply #5
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..

>implying that Linux player not locking file = none do on any OS

Reply #6
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.

>implying that Linux player not locking file = none do on any OS

Reply #7
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.

>implying that Linux player not locking file = none do on any OS

Reply #8
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.

 

>implying that Linux player not locking file = none do on any OS

Reply #9
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.