Topic: Issue Tracking Systems (Read 5713 times)

JimH · « **on:** February 09, 2018, 05:20:31 pm »

In the poll I just started, a couple people suggested that our support might be better if we ran an "Issue" (aka Bug) tracking system.

I want to explain why we don't do that. I don't expect to persuade anyone that we're right.

If I were to draw a pie chart of classes of issues, these are the categories I'd choose:

Antivirus software problems

Driver problems

Bad hardware

User errors

Bugs we have fixed in prior builds

Bugs we know about but haven't yet fixed

I'll update this list as I think of other types of problems, but you can probably see where I'm going.

Those pieces of pie add up. A lot of what gets reported is noise.

That isn't to say that Media Center is perfect. We know there are problems, and we're trying to fix many of them. And you have pretty good visibility into what's going on. Not complete, but good.

If we had a tracking system, that would take time for us to manage it. It would also take time to explain to people, just as the current forum and wiki take time.

We have used such tracking systems a couple of times, when we worked for large companies. I was not impressed.

One of the problems with such a system is that the quality of what gets added varies wildly, according to who is entering it.

Another problem is that the information entered is often not enough to find the problem, if there is one. A sort of conversation must occur, so this takes extra time.

The current system works for us. Enough of our customers understand it that they know what to do when they want to report a problem.

There are many people on the forum who report problems very well, with enough information to be able to understand and reproduce the problem. We're extremely grateful for this help.

DocLotus · « **Reply #1 on:** February 09, 2018, 08:32:33 pm »

Hi Jim;
Could you please explain the "noise"? I may be a little dense tonight but am not sure what you mean.

Quote

Those pieces of pie add up. A lot of what gets reported is noise.

JimH · « **Reply #2 on:** February 09, 2018, 09:44:50 pm »

Noise, not signal. Information that leads nowhere.

In this case, I mean that there are a lot of problems that end up not being JRiver problems. Two threads with lots of examples:

Weird and Wonderful: https://yabb.jriver.com/interact/index.php?board=3;action=display;threadid=24031;start=0

Antivirus problems: https://yabb.jriver.com/interact/index.php?topic=86096.msg588759#msg588759

DocLotus · « **Reply #3 on:** February 09, 2018, 10:13:48 pm »

OK, got it.

mattkhan · « **Reply #4 on:** February 10, 2018, 02:23:26 am »

I can't think of many pieces of software that don't manage their backlog and their defects in a structured way. It is also quite normal to have an internal tracker and an external facing one. It is also normal to provide a controlled way to feed issues into that tracker, to merge and/or link issues that have already been logged, to prioritise if you want to do so, to link defects to features and fixes to releases (and hence self documenting release notes rather than multiple threads that would be lost to the mists of time if a wiki maintainer didn't cut and paste them to the wiki) , to tag issues to help categorise them.... The list of things you can achieve if you want to is quite long

Ie all of the problems you mention are solvable and in solving them you provide useful metadata that helps the user (and helps the developer).

The current solution is to store this information in unstructured forum threads with none of that metadata. The result is you get just the noise and no signal.

Put another way, the noise is going to exist no matter what so the question is how best to extract signal from that noise.

Of course I don't expect you to agree with me because you have stated your position before and you find the current approach works for you. You did ask about the user experience though and imv a decent issue tracker (used properly) is the thing that would really make the difference.

If you don't want an actual issue tracker, you could probably achieve a few key goals with either different forum software (or plugins for this one if they exist).

JimH · « **Reply #5 on:** February 10, 2018, 08:03:48 am »

With respect to the "unstructured" approach we take, I have a few comments.

Any bug that can be reproduced should be posted in the thread that announces the build. This often happens.

Any forum thread that helps document the program can be added to the wiki. I do this now. Anyone else who wants to help can do this.

You're proposing to bring order to something that often doesn't have a lot of order. There are just so many cases that it's difficult, if not impossible, to do. Many of the problems are related to specific versions or builds of an OS, or to specific drivers, or to other third party software. Many of these get solved by a subsequent update of the OS, driver, etc.

I would guess that no two people on the forum use the same

Motherboard
Ram
Drive
Video hardware and driver
OS build and settings
Antivirus software and settings
DAC
Amplifier
Build of MC
Output settings
Network configuration
File type

I must seem to be arguing with you, and I don't want to do that or appear to do that. I'm just trying to focus attention on how wildly divergent the equipment, training, and mindset can be, and I don't think it's entirely possible to sort it into nice neat boxes.

I also think the current system is a rich source of (somewhat unstructured) information, and Google search is usually a great front end to this information.

Edit: Case in point -- Here's a question that could never be answered by a wiki:
https://yabb.jriver.com/interact/index.php/topic,114338.msg790596.html#msg790596
and could easily be entered into a bug tracking system.

RD James · « **Reply #6 on:** February 10, 2018, 08:55:55 am »

The thing that frustrates me is when changes/features/fixes are discussed on the forum and then JRiver staff stops responding.
It's difficult to know if they have acknowledged the issue and are working on it, if it's been fixed in a beta version, if they don't consider it worth fixing, or if it was forgotten about.

A couple of months back, it seemed like JRiver staff were receptive to the idea of bringing the WASAPI option to "maximize device volume during playback" to ASIO playback as well, since DSD playback can break on many DACs if the device volume in Windows is set below 100% when bitstreaming, but it just seemed to be forgotten about.

Having an issue tracker would let people know whether it's marked as "open", "fixed in version ____", "wontfix" etc.
Discussions on the forum often seem to go on tangents (which is why I prefer threaded views to the linear display here) and become too large to keep track of.

mattkhan · « **Reply #7 on:** February 10, 2018, 09:56:24 am »

Quote from: JimH on February 10, 2018, 08:03:48 am

I'm just trying to focus attention on how wildly divergent the equipment, training, and mindset can be, and I don't think it's entirely possible to sort it into nice neat boxes.

I agree it will never be neat, there will always be stuff that doesn't fit any particular structure. However to my mind this is an argument for such a system not against it. Imagine if you had a bug tracking system that had one and only one way into it (a form of some description) and that made you record certain pieces of data (mc version, os and so on) and also allowed you to enter enter/pick labels to relate to more esoteric hardware. I would think you would by now have a quite large database that anyone could search to see if some issue affecting some particular hardware was known.

Same principle could apply to particular features of the software rather than hardware (though this would not be open to user input). Furthermore imagine if those labels were the same labels used for your wiki and it were possible to do one search and find defects/issues/releases associated with a feature as well as the corresponding wiki page.

To give an example... a thread from recent memory that should not have required so much effort to get to half an answer - https://yabb.jriver.com/interact/index.php?topic=114200.0

There are a whole variety of threads around DSP that have the same problem, an ongoing one is https://yabb.jriver.com/interact/index.php/topic,114295.0.html while anything convolution related is another. Google helps of course but it's often pretty time consuming to plough through search like that.

I do appreciate that this would be a non trivial undertaking to get right though hence the suggestion around the forum software itself. IIRC you don't like voting (like uservoice or similar) but some sort of "product" based labelling scheme might help (so you can tag a thread as relating to n "products" where a product might be a particular feature or hardware or version) as well as forum software that suggests related topics when you post (such as the way discourse works as well as something like stackoverflow). I also tend to think that breaking out feature requests to a separate, version independent, board would be useful and leave version & OS specific boards for defects might be a good thing. This would probably work better if you can create custom forms for the defect board though (as per the earlier comment) to try to ensure that only problems hit that board.

JimH · « **Reply #8 on:** February 10, 2018, 10:23:57 am »

Quote from: mattkhan on February 10, 2018, 09:56:24 am

I agree it will never be neat, there will always be stuff that doesn't fit any particular structure. However to my mind this is an argument for such a system not against it. Imagine if you had a bug tracking system that had one and only one way into it (a form of some description) and that made you record certain pieces of data (mc version, os and so on) and also allowed you to enter enter/pick labels to relate to more esoteric hardware. I would think you would by now have a quite large database that anyone could search to see if some issue affecting some particular hardware was known.

I'm not against that. I just don't want to devote precious resources to it. The information becomes obsolete fairly quickly because things like OS or driver problems often go away within a few months. You would still have to wade through information to find what you need. Search would help, but Google already does a better job. And you might think it's an MC problem but it isn't. It might be a file problem, for instance. Or a drive problem. Or a power problem. That's where the forum really works well. A tough problem often gets the attention of a number of expert users.

Quote

Same principle could apply to particular features of the software rather than hardware (though this would not be open to user input). Furthermore imagine if those labels were the same labels used for your wiki and it were possible to do one search and find defects/issues/releases associated with a feature as well as the corresponding wiki page.

That would be nice. Someone has to build it. Precious resources ...

Quote

To give an example... a thread from recent memory that should not have required so much effort to get to half an answer - https://yabb.jriver.com/interact/index.php?topic=114200.0

OK. You gave a good answer there, after he fumbled around a bit. Now someone can find that. It will still require a search. If they ask JRiver, someone may try to search for an answer or give a quicker (briefer) one. Either way, it is a search, and it's not something that can be filed neatly under a wiki topic.

Quote

There are a whole variety of threads around DSP that have the same problem, an ongoing one is https://yabb.jriver.com/interact/index.php/topic,114295.0.html while anything convolution related is another. Google helps of course but it's often pretty time consuming to plough through search like that.

Complex subjects will always take time to learn. My knowledge is limited. Same for the rest of the JRiver staff. We're fortunate to have users like you who will take the time to share their knowledge with those who are starting out.

Quote

I do appreciate that this would be a non trivial undertaking to get right though hence the suggestion around the forum software itself. IIRC you don't like voting (like uservoice or similar)

I don't think I've said that. I have said that I wouldn't care to choose our development path according to the number of users who want something. Tidal, for example, could easily soak up a lot of resources and then colllapse. We had that happen with QNAP. We need to decide for ourselves where the solid ground is.

Quote

but some sort of "product" based labelling scheme might help (so you can tag a thread as relating to n "products" where a product might be a particular feature or hardware or version)

I agree. It would be nice.

My overall problem is that the needs are many and the hands are few.

Quote

as well as forum software that suggests related topics when you post (such as the way discourse works as well as something like stackoverflow).

Great idea.

Quote

I also tend to think that breaking out feature requests to a separate, version independent, board would be useful

I don't think that would work for many requests. Some are OS specific. Mac look and feel, for example.

Managing requests would not be easy. I think we're better off to let people say what they want, see how others feel, then make changes if needed. That process is going on now with the multi-channel thread.

Quote

and leave version & OS specific boards for defects might be a good thing.

Maybe, but what about someone who asks for a feature that currently exists. Or someone who reports a defect that is just an incorrect setting (import, for example).

Quote

This would probably work better if you can create custom forms for the defect board though (as per the earlier comment) to try to ensure that only problems hit that board.

I personally don't like systems that require me to fill out a form to ask a question.

Thanks very much for all your thoughts.

Awesome Donkey · « **Reply #9 on:** February 10, 2018, 10:39:11 am »

Like having a weird problems/antivirus issues topics that link to other topics where a solution was found, having one for common questions with answers might help too (like a FAQ topic or something), so users don't ask the same question multiple times. Things that often come up include questions about why JRiver doesn't use full SoX (and just the resampler), Tidal/Qobuz support, MQA support, Chromium/LAV Filters/madVR plugin downloading questions/issues, moving files (this one comes up a LOT, especially between operating systems which isn't that simple), etc.

That way when somebody asks a question (in case they don't search or can't find an answer) a link to the common questions topic could be posted answering the question. Saves time having a dev/admin having to respond to posts in length.

Otherwise, I think the overall system with the forums is actually pretty good. I can't think of any other company that has an active community where users can talk to the developers/CEO and report issues. I've had experiences where I've had to go through different levels of canned support responses before even being able to get a response from a developer.

EJR · « **Reply #10 on:** February 10, 2018, 12:36:27 pm »

isnt that why issue/ bugtrackers have voting systems? to filter out the noise?

Awesome Donkey · « **Reply #11 on:** February 10, 2018, 12:56:25 pm »

Thinking about it some, any type of voting system would be prone to abuse/bias, IMO.

RoderickGI · « **Reply #12 on:** February 11, 2018, 08:19:39 pm »

Because of the resources required this is a thorny issue. I don't want a view into a Bug/Issue/Feature request tracker system that drives the business. Half the time a real bug is fixed in the time it would take to create a record in such a system. Sometimes it takes a couple of bites to get it right. But usually, bugs are fixed quickly, once they have actually been identified as bugs, and not one of the many other issues that can result in MC not working the way people expect.

When I report a bug or make a functionality request for something that is important to me I tend to save a copy of a link to the thread, and then go back and revisit that link and thread every now and then. It seems to me that each of the developers does a similar thing independently.

It would be great if there was a consolidated view that everyone could see for confirmed bugs and agreed functionality changes, so that everyone didn't have to maintain their own list, and users could check if something they wanted was already in motion. So some basic information; Date created, who reported it, link to a thread discussing it, status (on list, we're having philosophical differences, rejected after consideration, done), date closed, maybe some notes. Something like that.

A simple tracker could do that, and while it would take some developer resources, it may also save some developer resources, since they must be maintaining their list anyway. It would certainly save some user time, and a lot of regular contributor time as users could be directed quickly to an item in the tracker. Such a system would have to be maintained by JRiver and not allow user editing, as that would create a lot of noise.

But I'm not completely committed to the idea. I understand the JRiver business model, and that it has been successful. The ongoing conversations do keep the community spirit going, and a tracker may stifle that a bit, even if there is lots of repetition. The trouble is, repetition can burn out contributors as well, particularly when life changes and time is less available. Simple questions can be ignored because the stalwart contributors have already answered that a thousand times, and there are many threads on the issue. Do a search new users! But search skills are often part of the problem.

So a little bit of automated assistance and centralised consolidation of issues could improve the efficiency of the forum and user-based support.

michael123 · « **Reply #13 on:** February 12, 2018, 01:01:26 pm »

Quote from: JimH on February 09, 2018, 05:20:31 pm

If I were to draw a pie chart of classes of issues, these are the categories I'd choose:

Antivirus software problems

Driver problems

Bad hardware

User errors

Bugs we have fixed in prior builds

Bugs we know about but haven't yet fixed

I'll update this list as I think of other types of problems, but you can probably see where I'm going.

Those pieces of pie add up. A lot of what gets reported is noise.

So you don't even count the option user encountered a new bug.

Frankly, I don't remember I uncovered a bug in JRiver recently..

JimH · « **Reply #14 on:** February 12, 2018, 01:21:52 pm »

Quote from: michael123 on February 12, 2018, 01:01:26 pm

So you don't even count the option user encountered a new bug.

That's not what I intended. Of course our customers report bugs and we're grateful for that.

MusicHawk · « **Reply #15 on:** February 14, 2018, 11:55:56 am »

Current example of the need for a bug ("issue") reporting and tracking system:

A week ago a user reported a problem with MC and long file names. Matt noticed the report and suggested that release .100 would fix it. Since I was already using .100, I added to the post a similar problem I was stuck on, MC issuing a bogus "filename too long" error when no too-long path/file records existed, yet it caused MC to refuse to proceed.

Result of two show-stopping bug reports and effort by users to document it? Nothing. Silence from JR. (After no response, I resorted to a multi-day workaround.)

A user might conclude JR doesn't care, or certain problems are just tough luck. The problem might seem obscure, but MC has a built-in error message for it. Or maybe the problem is being addressed and will show up as a fix someday.

Or, since everyone at JR is busy, and forum messages quickly age out of sight, it might just be already forgotten -- an example of how the forum is not suitable for ongoing issues management and support.

But meanwhile, the silence doesn't help customers, and customer frustration doesn't help JR.

I don't mean to make this a discussion about specific issues and support, but likely there are many more examples of the forum leaving customers dangling...

PS: I found nothing in the Wiki that discusses how to do what I needed, or how MC handles long path/file names, and no mention of MC's error message about this or the actions or conditions that could trigger the message.

Another Wiki gap: I was connecting a laptop to my main MC PC over my LAN. Authentication wasn't happening, the MC client never requested it. I tried many things. Finally after 3 days "it just worked". But seeking help I tried the Wiki. There's lots of simple instruction, but nothing that explained, for instance, how on a client to get Authentication to be triggered. The Wiki Media Network page shows screens of older MC that do not match MC23, therefore instructions mention options that don't exist and overlook options that do exist. Terms are tossed about that are not defined or elaborated. More frustration...

I know from deep experience how hard it is to document something...anything. It is difficult to recognize all the aspects that need explaining, to determine the right depth of explanation, to anticipate points of confusion, to answer questions before they are asked.... and to keep it all current over time. I just hope that "hard" is not a reason to avoid something important.

JimH · « **Reply #16 on:** February 14, 2018, 12:13:34 pm »

Quote from: MusicHawk on February 14, 2018, 11:55:56 am

Current example of the need for a bug ("issue") reporting and tracking system:

A week ago a user reported a problem with MC and long file names. Matt noticed the report and suggested that release .100 would fix it. Since I was already using .100, I added to the post a similar problem I was stuck on, MC issuing a bogus "filename too long" error when no too-long path/file records existed, yet it caused MC to refuse to proceed.

Result of two show-stopping bug reports and effort by users to document it? Nothing. Silence from JR. (After no response, I resorted to a multi-day workaround.)

A user might conclude JR doesn't care, or certain problems are just tough luck. The problem might seem obscure, but MC has a built-in error message for it. Or maybe the problem is being addressed and will show up as a fix someday.

That problem was fixed within a day of the time it was reported. The initial fix didn't work right. That was corrected in another day. Unless you know something that I don't, it is fixed now.

Quote

Or, since everyone at JR is busy, and forum messages quickly age out of sight, it might just be already forgotten -- an example of how the forum is not suitable for ongoing issues management and support.

An issue tracking system might also have some latency.

Quote

But meanwhile, the silence doesn't help customers, and customer frustration doesn't help JR.

I think that it is unreasonable to expect JRiver to respond to every post or even most posts. To report on the status of a fix that is in progress is difficult and a waste of time. I realize you may expect that, but that isn't our promise to anyone. If this bothers you, the Stable branch is where you should be, if you aren't already.

Quote

PS: I found nothing in the Wiki that discusses how to do what I needed, or how MC handles long path/file names, and no mention of MC's error message about this or the actions or conditions that could trigger the message.

The problem has to do with a Windows limit. A Google search should show that. Our options page has a search window.

Quote

Another Wiki gap: I was connecting a laptop to my main MC PC over my LAN. Authentication wasn't happening, the MC client never requested it. I tried many things. Finally after 3 days "it just worked". But seeking help I tried the Wiki. There's lots of simple instruction, but nothing that explained, for instance, how on a client to get Authentication to be triggered. The Wiki Media Network page shows screens of older MC that do not match MC23, therefore instructions mention options that don't exist and overlook options that do exist. Terms are tossed about that are not defined or elaborated. More frustration...

Authentication is an area where we've been working in the last couple of weeks.

Quote

I know from deep experience how hard it is to document something...anything. It is difficult to recognize all the aspects that need explaining, to determine the right depth of explanation, to anticipate points of confusion, to answer questions before they are asked.... and to keep it all current over time. I just hope that "hard" is not a reason to avoid something important.

I think it's impossible to provide what you may expect. I'm sorry.

I also think the idea of a manual is out of date now. Search has replaced indexing. Nobody uses a phone book any more. Forums, wikis, and other resources provide the content. I often go to Amazon and read the reviews on a piece of hardware when I need help.

Hendrik · « **Reply #17 on:** February 14, 2018, 12:14:16 pm »

I doubt that you would be much happier with the particular answer to the long filename issue, but I've posted it anyway. Something marked "experimental" should be a hint that we know its incomplete, but also quite complex.

PS:
Its usually always better to not try to hi-jack some other thread with a vaguely related topic, but to report issues in the way that Jim always recommends to report them.

mattkhan · « **Reply #18 on:** February 14, 2018, 02:40:26 pm »

Quote from: JimH on February 14, 2018, 12:13:34 pm

I also think the idea of a manual is out of date now. Search has replaced indexing.

generally agree

Quote from: JimH on February 14, 2018, 12:13:34 pm

Forums, wikis, and other resources provide the content.

this depends on the content being available

some of the worst examples of this is where the underlying reference documentation is either poor or non existent and where you instead have to rely on piecing something together from an assortment of poorly worded and/or not quite applicable forum posts. This approach is also one that fails to show people what they don't know so features go unexplored.

IMV MC falls into that latter category too often because the content either doesn't seem to exist and/or has aged badly and/or is scattered across too many threads to comprehend easily.

JimH · « **Reply #19 on:** February 14, 2018, 03:57:51 pm »

I'm sorry, but I think your description is unfair. There is a wealth of information here. With anything humans do, some of it is great, some is not so great.

Many, maybe most of the problems we spend time on are things that don't lend themselves well to orderly documentation. Here, for example:
https://yabb.jriver.com/interact/index.php/topic,114370.0.html

Take a look at a few random threads and ask yourself:
1. Is there any documentation that might answer the question?
2. Is the problem simple enough to document?
3. Did the question get answered?

I'm going to lock this soon. I understand some of the people who have worked for big companies think that bug trackers are great. I don't. We're not going to add one just to satisfy those who do.

mattkhan · « **Reply #20 on:** February 14, 2018, 04:08:10 pm »

Quote from: JimH on February 14, 2018, 03:57:51 pm

I'm sorry, but I think you're being too picky. It's a wealth of information. With anything humans do, some of it is great, some is not so great.

I'm a user who looks for information on things in the places you say are the places to look and I often can't find it and/or it takes a relatively long time to piece it together. This isn't me being picky, it's simply me reporting that my experience of the available content is not that great.

JimH · « **Reply #21 on:** February 14, 2018, 04:09:10 pm »

mattkhan · « **Reply #22 on:** February 14, 2018, 04:14:16 pm »

leaving aside the issue tracker, as your position on that is pretty clear, how about running some sort of showcase board for the interesting/advanced things that people do? a bit like your weird and wonderful problems thread but instead of problems highlighting the good things people do with the software and also acting a bit like a bridge between the wiki and the forum for things harder to document. Alternatively it could be something like a thread per feature and asking "how do you use this feature?". Obviously it depends on people taking up the challenge to write something but it could produce some interesting content (which could then be cherry picked into the wiki).

(Edit: probably should have posted this in the other thread)

MusicHawk · « **Reply #23 on:** February 14, 2018, 05:22:55 pm »

I can't help pointing out how this very post illustrates the challenges of forum as a way to support/document things. I posted an example of a long filename problem I encountered. I just needed to change the name of the top-level folder.

It was NOT related to the experimental support of long file names, because my library did not actually have any long path or filenames, it had what I believe is a bogus error report claiming this, an error trap that stops the renaming process. I provided facts about the actual much-shorter filenames, expecting to help MC investigate. I also expected someone to potentially point out an error by me, if any, I even said so.

Yet in this thread there are criticisms that I should be aware of Windows path-filename limits, which I am (been developing database apps on MS platforms since 1981). Good advice, except not an actual factor in the problem I reported, since all the file names were much shorter than the max. Commenting on something that is hasn't been read is another example of forum derailment. I believe my original post is clearly stated. But now, inappropriate comments will be found via future searches that misstate the original post which quite possibly is still an open issue, more forum static.

I worked-around the direct folder rename problem by using MC's Rename action, which took hours (it does one file at a time). It processed exactly the same path\filenames, but never once complained about too-long, because there weren't any. In fact, the successful folder rename made it 2 characters LONGER (as I said in original post) but the non-readers didn't grasp this key fact.

"That problem was fixed within a day of the time it was reported. "
How would anyone know that? I had the problem in .100, which promised a fix, maybe so but not to the problem I encountered. That seemed worth reporting to JR. There is no mention of long filenames in the Release Notes of .101 or .102, so any further work on this is unknown to users.

Yes, probably I posted my issue info inappropriately (seemed right at the time). But without any method of organizing such reports, and no way to determine if it is received, in process, rejected, fixed, whatever, I would post the same report today if the problem again occurred.

Perhaps the gist of the comments about an issue tracking system or method is, we are too often all in the dark, which seems to waste everyone's time.

JimH · « **Reply #24 on:** February 14, 2018, 05:36:52 pm »

Quote from: MusicHawk on February 14, 2018, 05:22:55 pm

I can't help pointing out how this very post illustrates the challenges of forum as a way to support/document things. I posted an example of a long filename problem I encountered. I just needed to change the name of the top-level folder.

It was NOT related to the experimental support of long file names, because my library did not actually have any long path or filenames, it had what I believe is a bogus error report claiming this, an error trap that stops the renaming process. I provided facts about the actual much-shorter filenames, expecting to help MC investigate. I also expected someone to potentially point out an error by me, if any, I even said so.

I realize you think that the error is different. I saw that earlier. However, it may have been related to the fix that didn't work. Or it may have been something "special".

In general, we don't chase problems that only one customer reports.

I believe your problem is fixed now. Is that correct?

JimH · « **Reply #25 on:** February 14, 2018, 05:48:04 pm »

Your original post on the problem was, I believe, in the thread on the long filename problem. You said this:

Quote

I'm trying to rename a main folder that via subfolders contains much of an images library. I changed the names two other parallel folders of images, no problem (one of them had a file name 190 characters long!). But the most important (of course) folder rename can't pass MC's length test. But it should...

MC declares the folder name change "could create one or more invalid (too long) file names". The folder name change makes it 2 characters longer. The longest path+filename in this entire "problem" folder system is 170 characters. This one folder and its subfolders has 61,916 files.

As a test I shortened the longest file name from 170 to well under 100, made no difference, MC still refuses to rename the folder. Then next longest filename is 137.

I've read it a couple of times and I'm still not sure what you saw. Yes, it could be a bug we don't know about. But the fact that you found a file that had a 190 character name is suspicious. Maybe there were others. I don't know.

As I said, we don't pay a lot of attention to one-off problems. That's too bad for you if you find a real bug, but there are a lot of reports that turn out to be something else. It's a little like journalism. We need to verify a report with a second source.

RoderickGI · « **Reply #26 on:** February 14, 2018, 06:21:46 pm »

Quote from: MusicHawk on February 14, 2018, 05:22:55 pm

"That problem was fixed within a day of the time it was reported. "
How would anyone know that? I had the problem in .100, which promised a fix, maybe so but not to the problem I encountered. That seemed worth reporting to JR. There is no mention of long filenames in the Release Notes of .101 or .102, so any further work on this is unknown to users.

The best, or in fact often the only way to know what has been done is via the Release Notes, as you noted. They are summarised and pretty up to date if I am around, here: https://wiki.jriver.com/index.php/Release_Notes_MC23

As an aside I think the original long file name problem was different and was fixed in MC23.0.99, which highlighted another problem which was fixed in MC23.0.100, which is why there was no further reporting of fixes.

I don't think that fixed the problem you saw, which probably still exists, because you were doing something that most people wouldn't do: Changing the directory name via MC's Drives & Devices. That is pretty unusual. I would never have thought to rename a directory that way. I always use the RM&CF function, even though it is slower. It may fall under the category Hendrik mentioned, in that;

Quote from: Hendrik on February 14, 2018, 12:12:35 pm

But the fact alone that this support is hidden behind an experimental option means that it won't work with all use-cases in MC, and is known to be incomplete.

But I suspect it is a different issue altogether. It was just catching that error message because Windows was telling MC it wouldn't do the move for some reason.

PS:
I suspect that if you have MC set to update for external changes, backed up the Library, shut down all of MC, changed the directory name using Windows Explorer which would be very quick on a local NTFS drive, then started MC and ran Auto Import, the change would have been picked up in MC very quickly as well. I'm not sure if it would be as quick if your files were on a NAS, but it might be. Although every file would still need a tag change, the files wouldn't be copied from one directory to another one at a time, which would have been why it was slow using the RM&CF function. The thumbs.db files wouldn't have been an issue using this method, as Windows isn't moving them individually, just updating the NTFS tables underneath the directory they are located in. Besides, even if the message still appeared, you can tell Windows to apply your decision to move them all by ticking the box.

It is even possible that changing the directory name using Windows Explorer wouldn't have worked, as essentially that is what you are doing by using MC's Drives & Devices. If it didn't work you would be highlighting a problem in Windows, not in MC.

I have used the above method in the past, and it worked fine. But even if it didn't work for you, all you would need to do to recover would be to shut down MC, rename the directory back to the original name, then start MC and restore the Library backup you made. I have also reversed the process this way, when I made a mistake in the original renaming. The only risk would be if some files had their tags updated and some didn't, in which case an Auto Import run should change the tags back again. You would then be back to where you started and could use the RM&CF method.

MusicHawk · « **Reply #27 on:** February 16, 2018, 01:23:10 pm »

RoderickGI, thank you for understanding what I did and providing spot-on suggestions. I considered doing the folder rename outside of MC, but I was not confident how MC would recognize and adjust to it.

The huge factor (as I said) was that I had already used MC's Drives & Devices view to rename two other folders that were in parallel. It was one of them that had a 190 character path\filename, and MC did not complain. That method succeeded quickly and perfectly on two of the three folders. (I was surprised to find Rename as a folder option in Drives & Devices, but assumed it was a pass-through to Windows, and was there intentionally, so why not use it.)

Which leaves the third folder rename failure as a mystery. But since it was MC reporting a problem with the action I decided to stay inside MC to use RM&CF to get it done. I knew it would take quite a while, not a problem, except I did not anticipate the constant stopping and prompting about Thumbs.db.

If MC's error was actually a pass-through of a Windows complaint, that is a further mystery, because I rebooted, and because that folder tree was nothing special, just more data on my secondary data-only drive. Strange...

PS: Again this proves the pitfalls of the forum as support. RoderickGI's advice is solid, but the other comments and suggestions indicate lack of reading of the details of the original post. Probably just quick scans leading to semi-understanding. Not anyone's fault, no one has the job of carefully digesting everything posted and providing appropriate response. Yet to a customer with a problem, and perhaps not a solid understanding of all the tools, nuances, architecture, whatever, sorting through off-center responses and wiki and searches is often a mix of black hole and bottomless pit.

PS: Still, I agree that when good help does arrive here, it is because the JR world does much better than many companies at explaining the products, and staff and insiders make this forum quite valuable. In contrast, I just spent a fruitless hour on the phone with Western Digital tech support in India, trying to get a brand new hard drive installed in a laptop (something I've done a thousand times). I found nothing useful on their web site or forum about my problem: WD's cloning and maintenance tools did not recognize it as a WD drive so would not run, but a third WD tool identified it perfectly. Needing to clone, eventually the tech told me to contact Acronis and convince them their WD-branded clone tool does not work with a WD drive -- kicking the can right over the outfield fence. Not jumping into that quicksand, I solved the problem using a different clone-partition tool.

RoderickGI · « **Reply #28 on:** February 16, 2018, 04:04:09 pm »

MusicHawk, thanks for the positive feedback and well thought out response.

PS: I used to help people on the WD Community a bit, after I needed some help with a wireless drive and saw how bad the advice was there.

PPS: I gave up on Acronis years and years ago. Not a good company, in terms of product quality, reliability, or support. I'm amazed that people still believe their marketing lies, or put up with the lack of fixes for issues. The branded versions, while less capable, always seemed to work though. I guess the rot has seeped through to those as well.

INTERACT FORUM

Author Topic: Issue Tracking Systems (Read 5713 times)