Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - romney_yw

Pages: 12
Bug Reports / Problems syncing to root of virtual device
« on: June 18, 2018, 03:12:48 PM »
I'm experiencing problems when attempting to sync to the root of a virtual device. I'm not interested in Podcasts, Audiobooks or Video, so I just want my music files synced to the root of the device. The files are already organised by <Album Artist>/<Album>/<Track> <Title> on my PC, so I'm trying to use the 'preserve folders and filenames' option in the device settings (accessed via Preferences - Devices - <select device> - Configure - Settings).

The storage path for my virtual device is \\RASPI001\PiMusic\ I have tried a variety of different path entries for music files - some of which are based on other posts on this subject elsewhere on this forum. I've tried leaving the music files box empty, and also  specifying . \ or * for the path.

When I attempt to synchronise the device, I frequently get an error message "The storage folder '\\RASPI001\PiMusic\#\' no longer exists and may need to be changed in the device synch preferences". The # is something that MusicBee appears to have invented - it is not a character I have entered manually into the storage path.

When I check the settings from the device synchronisation page, the path shown for Music files does not necessarily match the value which I believe I saved via Preferences - Devices - Configure - Settings. The sync results obtained vary according to the actual path string entered, and I have attempted to summarise my observations below.

Devices - Configure              Error Message?        Synchronise - Settings          Sync action
<empty>                            Yes                          *                                        Fails with repeat error message
.                                         Yes                          *                                        Fails with repeat error message
\                                         Yes                          Virtual Device (PiMusic)\*     Fails with repeat error message
*                                        Yes                          #\*                                     Fails with repeat error message

If I change the music path directly in Synchronise - Settings, the following behaviour is observed
<empty>                  sync proceeds, but files are copied/renamed to \Music\ in the virtual device
.                               sync proceeds, but files are copied/renamed to \Music\ in the virtual device
\                               error message - the storage folder 'Virtual Device (PiMusic)\' no longer exists
*                              sync proceeds, but files are copied/renamed to \#\Music\ in the virtual device

This seems to me to be a bug. The path settings do not appear to be consistent between Preferences - Devices - Configure - Settings and Synchronise - Settings, and in no case does MusicBee actually synchronise or attempt to synchronise to the desired target folder i.e. the root of the virtual device.

I could probably work around this by accepting an additional (and unnecessary?) \Music\ folder on my virtual device, but I don't believe there should be any reason why I can't sync my organised music folders to the root of the device. I would be more than happy to provide any additional details which may be required to help debug this issue, and also to carry out any further investigation which may be useful.

Questions / Disc Count in WMA format
« on: February 12, 2015, 03:42:36 PM »
I use WMA format for my music files. I have noticed in Tag Inspector that "DISC COUNT" uses the "foobar2000/TOTALDISCS" Tag Code, which appears to be the only foobar2000 tag code used in my metadata.

I wonder whether "foobar2000/TOTALDISCS" is the tag code which MusicBee uses naturally for this parameter, or is it somehow a left over from the fact that I used foobar2000 (briefly) before I found the MusicBee path to righteousness?

If it is indeed a left over, what tag code would MusicBee use for this parameter when free of outside influence .....

Many thanks  :)

MusicBee Wishlist / Re: Library filters
« on: February 12, 2015, 03:28:26 AM »
Thanks for your suggestion, but I already use the column browser a great deal for the things that it is good at (Genre, Album, Artist etc.) I have only recently realised that you can make multiple selections in each column which increases its usefulness quite a bit. In reality, I do actually use the column browser to filter by Rating, but that was a simple example intended to help illustrate what I am requesting.

I use filters for rather more sophisticated searches (Title starts with Black, Composer contains Carmichael, etc.) which the column browser is not designed to do. And with only 6 columns available, I'd have to constantly re-assign the displayed columns.....

A lot of what I'm looking for could also be done using the search facility, including typing the target value into the box, or selecting a value from the database. However, multiple field searches cannot be stored for later and regular re-use - which is exactly what a filter provides.

 I stand by my original request - this facility would simplify my filter maintenance quite significantly.

MusicBee Wishlist / Re: Toolbar button - Auto tag, update missing lyrics
« on: February 11, 2015, 09:59:54 AM »
I can't find Tagging Tools: Remove Tags either  ??? Please can you make that command available too.....

MusicBee Wishlist / Set Toolbar Buttons - Scroll Bar
« on: February 10, 2015, 11:06:02 PM »
My tool bar is set to show all buttons in the main panel (with tabs docked in caption bar). I've now got 25 buttons configured (thanks to Bee-liever for his nice coloured toolbar icons

The "Set Toolbar Buttons" dialog has grown so tall that the "Update" and "Cancel" have been pushed down off the bottom of the screen and as a result I cannot click on them any more. :(

This dialog box really needs a scroll bar to scroll the list of buttons so that the dialog remains a workable size.

Please......  ;D

MusicBee Wishlist / Popup Help on column headings
« on: February 10, 2015, 01:50:58 AM »
I often try to cram so much data onto my screen that some of the columns are only just wide enough for the data. Under these circumstances, the column name is frequently wider than the column and is displayed as Di.... or something similar.

It would be helpful if the full column name was displayed as a pop-up help when the mouse pointer is hovered over the column header - just as the tab header is displayed when the mouse is hovered over a tab. My tabs bar is set to Horizontal (Caption Bar) in case it makes any difference.

Questions / Re: Updating Album Duration & Album Track Count
« on: February 09, 2015, 10:04:09 PM »
Thanks zak - that explains why these files show a slightly different length when viewed with "another" player, though most (out of four!) show values which agree with MusicBee. Interestingly though the all players I've looked at seem to show the same overall album duration, and therefore most of them show the same discrepancy as the one I originally noted in MusicBee. It's clearly all down to the way in which the track length is calculated. And I'm using variable bit rate too ......

Thanks again for you help.

MusicBee Wishlist / Library filters
« on: February 09, 2015, 01:09:36 AM »
I use filters quite a lot for examining & cross-checking my tag data. I find I have a number of filters set up which are almost identical, save for the target value (e.g. Rating = 2stars, Rating = 3stars, Rating = 4 stars).

I keep hoping for a dummy value to put into the filter definition, which would pop open a dialog box when the filter is applied, so that I could enter the specific value I'm looking for. (e.g. Rating = ? and I supply 2, 3 or 4 as required).

The Rolls-Royce version would provide a drop-down list in the dialog prompt which is based on the data already in the database, so that the value for the filter could simply be selected. It would probably need to allow for a value to be entered as well, so that a filter such as Title starts with ? could be used to find all titles beginning with "Blue", rather than looking specifically for "Blue Moon" or "Blues In The Night".

I appreciate that this might be tricky to implement for more sophisticated filters, but if it was possible only for one field in a filter, it would simplify my filter maintenance quite significantly.

General Discussions / Re: GUI changes for v3.0
« on: February 09, 2015, 12:31:47 AM »
after all these years, i still shudder using the ribbon interface in office tools

I'll vote for NO ribbon as well. It could have been good, but just wasn't. I'm still using Office 2000  :-X (And don't get me started on Windows 8 .....)

Questions / Re: Updating Album Duration & Album Track Count
« on: February 09, 2015, 12:22:22 AM »
I've done some more detailed research.

It seems that different sources of tag data can show different lengths for some tracks by a second or so, and the same track may possibly be quoted as a slightly different length on a different release (e.g. original album and greatest hits compilation). This could well be due to slight errors arising from the way the time value is actually stored. So a track which is about 3 minutes 53.5 seconds will sometimes show as 3:53 and sometimes as 3:54.

So on balance, it is probably the Album Duration which is correct, with minor differences in the length of some individual tracks causing an apparent error in the calculated total duration.. On a CD with 20 or so tracks, this can easily mount up to about 10 seconds discrepancy over the full duration.

I think I was probably trying to be a bit too clever while investigating a different problem! Apologies. :-[

Questions / Re: Updating Album Duration & Album Track Count
« on: February 08, 2015, 05:02:37 PM »
I have installed V2.5 RC1 update. I have reset my preferences to "each album in its own folder" and my greatest hits albums are now correctly displayed as 7 separate albums, each with its own tracks (only).  ;D I believe this patch contains the same version as the RC1 update?

There is still a small discrepancy between the Album Duration values displayed in MB and the total time calculated by summing the individual track times using boroda74's Library Reports tool. My Excel spreadsheet appears to confirm that the Library Reports calculated value is correct. Album Duration is between 5 and 10 seconds greater than the calculated sum, for albums ranging from 38 to 79 minutes.

I wonder if there is a problem with the way the Album Duration is calculated, or if this is simply a cumulative error arising from the way in which the time values are stored? For my own use, these discrepancies are small enough to be of little consequence, but I guess it would be nicer if they can be resolved without too much effort.....

Many thanks indeed for fixing this so quickly.

Questions / Re: Updating Album Duration & Album Track Count
« on: February 07, 2015, 02:40:15 PM »
Many thanks for the feedback - I begin to understand what is going on. But there's something not quite right here somewhere.  ???

My music files are organised on traditional lines - a folder for each artist, with sub-folders for each album. In general, I use the Organise Files function to maintain that structure. My Edit Preferences - Sorting/Grouping settings currently specify that files for each album are organised in their own folder.

I actually have 7 Greatest Hits albums in my library. The first in the list (currently Heart) shows correct values for Album Duration and Album Track count, but the remaining six all show the same erroneous values of 105 tracks and 412:32 duration as previously reported. I still don't quite understand where those values come from, as they are not the correct total for all my Greatest Hits tracks - not even if I exclude the Heart album which seems to be displaying correctly....

If I look at "Artwork" or "Albums and Tracks" views and filter for Greatest Hits, I can see 3 albums. The first album shows the artwork for Eurythmics: Greatest Hits, but includes tracks from both Eurythmics and Fleetwood Mac. The second album shows artwork for Heart: Greatest Hits and (correctly) only includes the tracks from that album. The third entry shows artwork for Linda Ronstadt: Greatest hits, but additionally includes the tracks from Robbie Williams, Shania Twain and Texas.

I don't really understand how this can be - I would expect either that all seven albums would be grouped together as one, or all would be displayed correctly. I haven't yet spotted anything which would make them group as they are currently doing.

If I change my grouping settings so that an album is defined by the fields Album Artist and Album Name, the seven albums are displayed correctly - each with only the correct tracks for that album.  ;D The Album Track Count is now correct for each individual album, but the Album Duration is about 10secs larger than the totals calculated using Library Reports from boroda74's Additional Tagging & Reporting Tools. I'm working on an Excel spreadsheet to help analyse my album durations in the hope of identifying where the discrepancy lies. It's currently taking a bit of time to get right, so I'll report again in due course. :(

I'm quite happy to keep the new settings identifying my albums by Album Artist and Album Name, but I'm slightly puzzled why the "files in their own folder" option doesn't work as I anticipated. It certainly seemed to be the best match for my current situation.....

MusicBee Wishlist / Re: Auto-save settings & database option
« on: February 07, 2015, 11:50:10 AM »
Redwing - I fundamentally agree with the need to address this problem. I'm just not convinced that an autosave every x minutes is the best solution.

I agree with zak - the system should be able to write changes either to configuration or tag data to the disk, whenever a user clicks "Save". I know that database management systems work in that way (hence my earlier thoughts on incremental changes). I don't know enough about MB file structure to understand whether this approach would require a major change or just a simple tweak ...... There is presumably a good reason why it currently behaves as it does.

And I also agree that Steven is more than capable of handling whatever technical issues are involved. MusicBee is simply amazing, and the speed with which he is able to implement patches is stunning. I wouldn't dare to offer advice in that respect.

But I do feel we need to understand what we are lobbying for...... I'm sure that we are all broadly in agreement - as always, the devil is in the detail ....

Steven - I imagine that you have been monitoring this discussion. Do you have any thoughts about how best to address this problem?

MusicBee Wishlist / Re: Auto-save settings & database option
« on: February 07, 2015, 12:24:56 AM »
Why aren't changes to the database and settings files written to disk straight away, making an auto-save option unnecessary.  ???

MusicBee just makes incremental changes to a database and some XML files so I'm curious as to the rationale for it to wait until the program closes.

That would waste system resources and annoy the user because MB would then have to keep overwriting setting files and database file with almost every edit and adjustment as it has to know the last used configurations and has to keep database in sync with every tag changes made, which would be dreadful especially to people with a huge collection (a large database file).

But the same issues would also apply for an auto-save function. If MB saves when the user clicks "Save", the user will at least have some visibility of the cause...... With auto-save, these issues would suddenly occur without any warning as a result of the background process triggering after X minutes, and the user may not realise why his system is not responding. Which will surely be much more frustrating ......

But it is equally frustrating to lose a large number of changes, if MB crashes at the end of a particularly long editing session. At least with a manual "Save Changes" function, the user would have some degree of control over when the changes are saved, and would be less surprised by a temporary loss of performance while this is carried out. This would be rather more graceful than the current need to restart MB - whether by closing and opening manually, or triggering the restart function by hot-key..... (and this current need to restart is not at all obvious to the uninitiated user either!)

I agree with zak - changes to the database and settings files should be written to the disk straight away. However, I accept that there maybe some need to compromise for reasons of performance etc.

I think currently clicking on save button on any dialogs immediately updates relevant settings files. If you had changed the toolbar button coloring option from preferences, instead of from its context menu, and had clicked on save button, the settings file would have been updated right away. Also I don't see much need for a command to save configurations because currently you can exit and relaunch MB with a hotkey that will update not only settings but also database.

Redwing - your earlier comment suggests that MB behaves differently when the toolbar configuration is changed via the Edit button on Edit Preferences- Layout 1 from what happens if I rghit-click the toolbar and choose Configure Toolbar from the context menu - even though both operations appear to arrive at the same Set Toolbar Buttons dialog. Are you sure that is correct? {Ah yes - because the changes are only saved to disk when I click "Save" on Edit Preferences I suppose.]

I believe that configuration settings are stored in relatively small XML or INI files, and I don't think there is any reason why such changes could not be saved to the relevant files immediately the user clicks "Save"? But I have no detailed knowledge of the file structure, so I could well be a bit wide of the mark here....

I can appreciate the problem with the database file, and trying to keep it in sync with tags in hundreds (or thousands) of separate music tracks. It does seem a little inefficient to have to save the entire database file every time the user makes a change to the tags in one track. Would it be possible for individual changes to be saved as incremental updates, which are rolled into the main database file when MB exits - or if unsaved increments are found on start-up (presumably following an unexpected shutdown)?

Actually, if the changes to tag data are saved immediately to the individual track file, MB could check the database against the individual tracks on restart (with an appropriate warning to the user) if an earlier unexpected shutdown was detected. Each track is effectively its own set of incremental changes, and the database could be verified against them when inconsistency might reasonably be anticipated. (A bit like the way that Internet Explorer offers to restore your last browsing session when it detects that the last shutdown was unexpected.)

Sorry for the long post, but there are some serious questions here which need to be properly understood in order to suggest the best solution to the problem. I'm now even less convinced that auto-save is the correct way forward......  ::)

Tips and Tricks / Re: Exit MusicBee to save changes
« on: February 06, 2015, 12:16:24 AM »
I'm not completely certain that Auto-save is the best solution to the problem. I sort of expected that any changes were saved when I clicked the "Save" button. However, I've added some comments to the Wishlist and a slightly qualified +1 as the problem certainly needs to be resolved somehow ...... :)

Pages: 12