2013-07-24, 16:18
Good afternoon MariusTh86,
Thanks for your thoughts and actions on the early observations.
1) My purpose is to let you know about something I have tested to have same consistent results on multiple attempts and not just once, even after resetting the computer or reinstalling ViMM. In this case the 'stuck' folder you mention, is always stuck for NFO files. So even if the user utilises the 'Clean All' command once, the NFOs won't get erased, with the user not knowing this, unless happens to visually review the folder structure, to then trigger the command a 2nd time. Thought this might be somehow important because it could generate an issue for media centres finding a local NFO when displaying info or scraping, one thought to have erased. At the moment it is, at first glance, and unreliable command because it is a command that needs to be trigger twice to do its full job and no one will know this. If ViMM detects the just 'cleaned all' folder as stuck, wouldn't be better to have this command auto-trigger itself a second time to complete its task 100%? Just brainstorming here. Now, if you have tested this function with OK results, no stuck folder behaviour and no double-triggering the command 'Clean All', then it is a local issue on my end, and please disregard query.
2) So if the user changed the NFO names at least once over a period of time, and has added new metadata along the line since then, how the user will know immediately which NFO has been updated if there are more than one NFO file present? Please have in mind here too that there is, on top, an extra difficulty given by the bug on item 3). One could perfectly be updating new metadata to the NFO that actually doesn't get picked up by the media centre, because there will be multiple NFO, all of them differing in their metadata. Perhaps you have reasons for not seeing it this way, and thinking there won't be any issue?
3) Cool, looking forward.
4) Cool. I share your view too, sometimes original language posters are so great. Knowing now that ViMM will put the 'empty-language' poster first in line for download, and realising, in this particular case, that the no-language poster was wrongly labeled on TMDB since it is actually the original Japanese poster, I have labeled it as Japanese language, and that should do it. Will test a new fetching to see if ViMM brings in now the default English-language poster that ViMM manual search is given as default by TMDB. Will have to wait a while though for TMDB to update its unbearably slow API.
5) Thanks, I know. I am currently testing ViMM as an average user would do and the experience resulting from that: relying almost entirely on clicks and on what they can immediately recognise/see/do/bring on/from the mane pane.
New observation:
1) This is just food for thought and currently doesn't constitute an issue interfering with the work on ViMM: Working ViMM in full screen is something that I will be testing next at some point, but so far I have noticed some strange behaviour with opened windows, such as the 'Manual Search' or the 'Edit Metadata', if the main pane is selected with a click, or some of these windows are minimised. These opened windows just get relegated to the background, behind the full ViMM main pane, and can't be brought back to front unless one quits full view to find these opened windows. Full view work has its complications and perhaps needs to be approached in a different way (??): I need to be capable of bringing in all my tools at any given time, if I want, right there on display. That is one of the purposes of maximising the working area; the reason why in many applications that deal with multiple settings and information display for the user, it is likely to find hovering tool bars or even folder structure hovering windows that can be closed/opened without getting lost, so the user doesn't have to quit the full view just to check how things are going at the folder level after a particular change or find the "lost panes".
Best wishes,
CF
Thanks for your thoughts and actions on the early observations.
1) My purpose is to let you know about something I have tested to have same consistent results on multiple attempts and not just once, even after resetting the computer or reinstalling ViMM. In this case the 'stuck' folder you mention, is always stuck for NFO files. So even if the user utilises the 'Clean All' command once, the NFOs won't get erased, with the user not knowing this, unless happens to visually review the folder structure, to then trigger the command a 2nd time. Thought this might be somehow important because it could generate an issue for media centres finding a local NFO when displaying info or scraping, one thought to have erased. At the moment it is, at first glance, and unreliable command because it is a command that needs to be trigger twice to do its full job and no one will know this. If ViMM detects the just 'cleaned all' folder as stuck, wouldn't be better to have this command auto-trigger itself a second time to complete its task 100%? Just brainstorming here. Now, if you have tested this function with OK results, no stuck folder behaviour and no double-triggering the command 'Clean All', then it is a local issue on my end, and please disregard query.
2) So if the user changed the NFO names at least once over a period of time, and has added new metadata along the line since then, how the user will know immediately which NFO has been updated if there are more than one NFO file present? Please have in mind here too that there is, on top, an extra difficulty given by the bug on item 3). One could perfectly be updating new metadata to the NFO that actually doesn't get picked up by the media centre, because there will be multiple NFO, all of them differing in their metadata. Perhaps you have reasons for not seeing it this way, and thinking there won't be any issue?
3) Cool, looking forward.
4) Cool. I share your view too, sometimes original language posters are so great. Knowing now that ViMM will put the 'empty-language' poster first in line for download, and realising, in this particular case, that the no-language poster was wrongly labeled on TMDB since it is actually the original Japanese poster, I have labeled it as Japanese language, and that should do it. Will test a new fetching to see if ViMM brings in now the default English-language poster that ViMM manual search is given as default by TMDB. Will have to wait a while though for TMDB to update its unbearably slow API.
5) Thanks, I know. I am currently testing ViMM as an average user would do and the experience resulting from that: relying almost entirely on clicks and on what they can immediately recognise/see/do/bring on/from the mane pane.
New observation:
1) This is just food for thought and currently doesn't constitute an issue interfering with the work on ViMM: Working ViMM in full screen is something that I will be testing next at some point, but so far I have noticed some strange behaviour with opened windows, such as the 'Manual Search' or the 'Edit Metadata', if the main pane is selected with a click, or some of these windows are minimised. These opened windows just get relegated to the background, behind the full ViMM main pane, and can't be brought back to front unless one quits full view to find these opened windows. Full view work has its complications and perhaps needs to be approached in a different way (??): I need to be capable of bringing in all my tools at any given time, if I want, right there on display. That is one of the purposes of maximising the working area; the reason why in many applications that deal with multiple settings and information display for the user, it is likely to find hovering tool bars or even folder structure hovering windows that can be closed/opened without getting lost, so the user doesn't have to quit the full view just to check how things are going at the folder level after a particular change or find the "lost panes".
Best wishes,
CF
