REQUEST: export error reports to a TXT file

In a situation like when the user is coping with an action a very long TITLE to FILENAME, that is way too long to be accepted in it, Mp3tag will open a message box with an error message

File "M:\Music\X.mp3" cannot be renamed to "M:\Music\XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX yyyyyyYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ.mp3".
The system cannot find the path specified.

This is of course helpful. But when there are many such cases [errors in one message], then the user is not able to remember the TITLEs which have to be dealt with- that is when there are like a 100 of them in a set of 20 000. And so the user has to manually copy the list to somewhere else as it is impossible at that moment to do anything other in Mp3tag than clicking the >>OK<< button of such message


How bout if that message box aside >>OK<< button would also have a button named >>EXPORT<< or >>REPORT<<- that would copy the message to a TXT file? Just like the current Export window this export-message could have a box in which a path and name of the report could be specified [and that path and name should be remembered between messages]. And that TXT report could / should be opened immediately after its creation for the convenience. That's for starters


In a more advanced mode there could also be some kind check boxes that would turn on and off different kinds of errors on the list [or just including or excluding them form the exported report], thus differentiating for example between files that would have had a too long FILENAME / PATH and those that were simply missing [as they were removed from their folder without reloading / refreshing of the list of files in Mp3tag]. Although if I am not mistaken that particular example is rather bad, because currently Mp3tag does not differentiate between such two problems [to many signs for a file that was supposed to be renamed as opposed to a complete lack of the same file]

2 Likes

Usually you get such a message right while you execute some function or action.
This modifcation usually leads to some kind of standardized pattern, esp. with filenames.
So you can filter for the files that do not match the intended result ($num(%track%,2)_%artist%_%title%) like
"$if($eql(%_filename%,$num(%track%,2)_%artist%_%title%),1,0)" IS "0"

You can see straight away how many and which files have not been treated and you can quickly apply a new rule to these cases.
A manual scan and comparison of 2 lists does not look too promising to me.
And the good thing: you can already do this, no new implementation is required.

1 Like

Even if you think that everything is tip top and so you execute a long group of complex actions, go out of the room because you are processing the whole database and you discover that something went wrong for hundreds of files after you return- on an unknown basis as there are a lot of them in that group? Then the work is already done [for most] and not done [for erroneous cases]. And you would still use a filtering expression to find / compare what went wrong even if export report function would be available? And what if a in the middle of that check up, the power goes out or your operating system crashes- how will you filter the results after a boot up if you were only processing some pre-selected files [not the whole database]? Did you remembered to save those pre-selected files to a playlist? And if yes, will that list will show you what files were unaffected if the filtering fails at it? And how will you know if the filtering failed at this or was that filtering 100% correct in finding all the unaffected cases?

The good thing is that this functions is already there: we only need some sort of SAVE button; maybe just a copied inner-workings / interface of the current Export options

If that is the case then I do not get an error message to save.
Can't you just stay with concrete examples instead of phantasizing about purely academic constructions?
I mean: the errors crop up in reality. So there has to be a just as concrete cause. You try to get to the root of things for this cause, correct it and see if there are other causes. And this can all be done with filtering which then deals in a much more efficient way than looking at each file individually, as there can be "hundreds" of cases with the same cause and just one odd one out.
So again: it is not really necessary to save the list. Yes, it is one of the many options but is not there at the moment.
But there is another way to get a similar result which is already there, perhaps you find a liking in it.

You do, if you save it before the crash; which will take you one click of a mouse as opposed to figuring out a filtering expression and then bla-bla-bla-you-know-what?

If I would only plan for the current state of things then my system in Mp3tag would need a possible correction every time something new would appear in it. And some times it would just fall apart as the data would be incompatible with the system. And just how many times in my life have I encountered various e-systems that lacked a foresight for even most basics things? Like for example including an ability to use diacritics signs that are not present in my native alphabet - in a government database of my country needed for buying / selling of the land, which was suppose to keep track of exact names of both natives and foreigners; and so the electronic database was sometimes useless without looking at the the paper records?


But that was outside of Mp3tag and analogies are too much for some. So what else can I say in direct relation to Mp3tag? Evoke the example that I already given- and that additional statement, than currently Mp3tag shows two different states as one [error of lack of file and of too long FILENAME]?

By the extension of that logic the current Export options are somewhat of an overkill, because user can utilize the Filter Box; and save Playlists; and arrange Colums - so what else would the user need and could think of utilizing?

No no no, we need Exports because list of values from tag fields are a completely different thing and can be very useful. You can for example go so far with current Exports as swiftly create data that you later put into Notepad++, which in turns spits out a list and number of all the artists present in your files - thus helping to do that for what tghe Mp3tag was completely not designed for and yet useful. But even more export functions / options in other place of Mp3tag- those we absolutely do not need!!!

Aaa, so that is the difference... there are useful lists and useless ones. And the user is not the one who is suppose to decide which are which

If you look very carefully then you will not find a single word by like "we don't need this function".
All I say: there are solutions already available. So if you have the pressing problem that you frequently get hundreds of failures then I would take what is already there.
So again, we are at the point: is this a discussion to deal with the problem of error messages and how to deal with them or implementing one special feature under all circumstances?
Just a small indication of the effort:
While message boxes are something that is included in system libraries and you only have to call them with a single line (give or take a few), you would have to implement a whole new dialogue with file selection and yet more possible error messages ...
As there are already functions available that help you to avoid the errors for the next run, I would first of all use these before I would wait for the implementation.

1 Like

The purpose of this topic was to upgrade an already available function

Because even the most basic thing, a simple SAVE report button, would be a noticeable improvement. And as I said, the content to be saved is already there, being generated by Mp3tag and even shown to the user

It's a modification.
For reasons that I explained in length I do not see any upgrade.
But that is just my opinion.
On the other hand, looking at

As the functions to narrow down the cause why

are already there even without

Yet, perhaps it is possible with very little effort to allow the text of the message box be copied to the clipboard so that you can have a look at it in the editor or something. You would have to open that anyway.

And just like with current Export feature, there could be anotheR popup with a question "Display Report file now? - YES / NO]