Some actions cause inexpected outcomes and/or freezing of program

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Some actions cause inexpected outcomes and/or freezing of program

Ollekebolleke
I've been working some time with the program which works for most of the time fine. However, there are some points which could be improved to my opinion (in decreasing importance order):

- Freezing of program: when a file is physically deleted, one should always take care that no parallel (background) task is running on this particular file.  If this happes, the program freezes. For example, the program is still analyzing the spectrum and one deletes that file, the program freezes. This can easily happen if one has analyzed the spectrum of one file, next right click to delete another file (which however also triggers the spectrum analysis for this file since the spectrum window is visible). Or, the directory is being refreshed while some file is deleted. This also gives sometime a TImplement.... error.

- Showing spectrum is an important final check since the prediction is not always 100% reliable. However, it takes some time to do such analysis and this could be considerable if the number of files is large. It should be an improvement if one could select some collection of files at once (by CTRL-SHIFT actions) and next start the spectrum view analysis. After this analysis is done, one could view the files one after another very fast. If one does such a spectrum analysis on a collection of files with program as now designed, some of the files are indeed analyzed, but others aren't. It's not very clear how the programs handles this.

- Playing  a file blocks some actions like for example renaming or deleting this file. So, one must always first stop playing. To my opinion, playing should have the lowest priority and being topped automatically in the case of physcially deleting a file. It's also a tricky action since it seems to take some time before the file is effectively released after stop playing (although I've put mixing with next track off). So if one stops playing, immediately do a delete action, in this case no error message is given but the file is still present on the disk while not anymore present in the database list. So after refreshing one finds out it's still present since returning in the list.

- Situation: If the filter field is being used with some input in it and one edits also a specific field of a file (for example the artist / file name by double-clicking). Next we want to exit the file field edit by using the escape key. However, the input in the filter field is now also erased.

- Right click shows the option 'Copy to map'. Could also 'Move to map' being added?

- If playing a file and the program jumps to the next file in the list, but this file is not physically present anymore on the disk (while being listed in the database) the program jumps to the next file in the list but keeps on jumping to the next, even if these files are physically present

- Finally, a detail. I'm Dutch spreaking and the delete actions say's "xx bestand zal worden verwijdert" on the delete action. This should be "....worden verwijderd" in correct Dutch. Also present in other positions with "worden ..... verwijderd"