JRiver Media Center ("MC") populates an album's Notes tag/field with a meaningless term ("Term"). A Term is of the form "x[Varies]," "x," "xx," "xxx," or "xxxx" (without the double quotes), where x is a variable that represents a lower case letter (or digit if the Term contains only one character). Examples are a[Varies], 9, d, qq, ttt, ffff, where x = a, 9, d, q, t, or f, respectively. Initially, each Term was of the first form. Recently, that form rarely appears, making searching for Terms impractical and inefficient.
I first discovered the problem by accident while displaying the tracks in Files view (with the Notes field displayed). A quick scan of all tracks will reveal any Terms because they are brief and of a limited number of forms (based on my experience). Another user may discover that Terms take other forms.
The population is apparently at the album level, i.e., an album’s Notes field is populated with a Term, causing the Notes field of every track of the album to be populated with the Term. The population is intermittent and there appears to be no pattern to the albums affected. It is unknown whether the problem occurs only if the Notes fields of tracks are populated or edited.
While the problem was discovered in v32 and is assumed to have arisen in v32, the problem may have occurred in prior versions I used, but remained unnoticed, or prior versions I did not use and been carried over to v32.
The problem could be potentially costly if valuable data are overwritten. Some of my tracks' Notes fields contain text thousands of characters in length (the maximum number is at least 15,000). The data represent many hours of research and composition of text. I estimate that, since I began populating tracks' Notes fields, I have populated about 10–15% of the approximately 8,000 tracks in my library and spent over 1,000 hours to gather, compile, and organize the data and enter them into MC. The loss will increase by orders of magnitude if, as is my goal, I populate the Notes field of every track in the library and of future tracks as the library continues to expand.
Until the problem is fixed, I have adopted two remedial measures to prevent data loss. These measures are time-consuming and one of them (the first one discussed below) must be diligently applied after each MC session (whether to listen to music or edit the Notes field or other fields of a track) out of an abundance of caution in case the problem occurs even if the Notes field of no track is populated or edited.
In brief, one measure is to use a file/folder comparison program to compare the files in a music library (Source) with the files in a backup (Target) using the "backup" execution method (which causes Target to mirror Source). Tracks/files may be updated in Source because their album's Notes fields have been populated with Terms or because the user may have populated or edited a track's or album's field. The program's comparison window helps identify the updated files and suspect files can be examined in MC before deleting them (and replacing them with unaffected backup copies) or backing them up.
A second measure is to use a text editor such as Microsoft Word to compose and save text before copying it to a track's Notes field. Word provides a means of saving the data in a track's Notes field that is independent of the track's file (in case it is corrupted and unreadable or its Notes field is populated with a Term) and independent of using a program such as MC to access the data in the field. Having both (1) the raw, unformatted data in the Notes field and embedded in a track's file and (2) the formatted data in Word for better readability and in a file independent of a track's file provides peace of mind.
A full discussion of the problem and these measures is contained in the attached memorandum for the use of MC's management and developers.
