Some actions cause inexpected outcomes and/or freezing of program

classic Classic list List threaded Threaded
3 messages 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"
Reply | Threaded
Open this post in threaded view
|

Re: Some actions cause inexpected outcomes and/or freezing of program

Fake No Funk
Administrator
Thanks for your detailled feedback!
Most of your issues are fixed in the latest version as of 04-17-2019

About the freezing etc: I could not reproduce: While the spectrum is analyzed, the file is locked an cannot be deleted, the OS does not allow this...
Reply | Threaded
Open this post in threaded view
|

Re: Some actions cause inexpected outcomes and/or freezing of program

Ollekebolleke
This post was updated on .
Thanks for the update. The precalculation of the spectrum is really helpful in minimizing the time needed to select songs. In mean time I've analyzed already at least 30000 files this way, so it speeds up a lot. However, doing this I found still some smaller issues:

- Sometimes files are present without containing any valid audio stream (for example by using another program which has prefiltered invalid streams from the original file, very rarely leaving no audiostream at all anymore, although still being named for example *.MP3). Although the bitrate frequency analysis doesn't have any problem with it (it shows the file correctly as corrupt) the new added pre-calculation routine has some problems with it: it immediately aborts with one kind of TImplement... SQLITE-database error, suggesting that the frequency database is corrupt. Manual removal of the corrupt audiofile can solve this issue but it would be more logical if the program can handle this too.

- Sometimes it happens that after the pre-calculation spectrum has been calculated and showing correctly if the file is selected, the white histogram bitrate line is still missing, also if one toggles it on/off/on manually. Only manual recalculation (F5) of the visual spectrum solves the problem.

- I also have a strange behavior if the visual spectrum is visible and the file is being played. When the song is finished, the program continues with the next song and it logically also tries to open the next correlated spectrum, but since taking a small portion of time, the program skips again playing the file and continues with next file, opens the spectrum again and again skips playing, etc. Only way to stop this behavior is to close the visual spectrum window and wait some time while the list of skipped files are being processed. Then everything works fine again.  

- Finally: the move command works fine but only if the move is between directories on the same disk drive. Otherwise, it's aborted.