Re: [SlimDevices: Beta] rescan fails to find new muisc, 7.6.0 - r31134
It does work for me so the rpm build while using SQlite is not affected. Sometimes you have to hit refresh in the browser to se updated counts on album etc. Sometimes I got fooled by the "new music" list, once in every 1000 files the tags are exactly as you want them even when copied music from a friend. So when not edited and stored again, they have the original date and cpuld be lurking anywhere in that list -- Mnyb Main hifi: Touch + CIA PS +MeridianG68J MeridianHD621 and assorted amps SiriuS, Classe' Primare and Dynadio speakers, Contour 4 Contour Center, and Contour 1.3SE for the rear ch. Rel Stadium 3 sub. Bedroom/Office: Boom Kitchen: SB3 + powered Fostex PM0.4 Miscellaneous use: Radio (with battery) I use a Controller various ir-remotes and a Eee-PC with squeezeplay to control this Mnyb's Profile: http://forums.slimdevices.com/member.php?userid=4143 View this thread: http://forums.slimdevices.com/showthread.php?t=80821 ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/beta
Re: [SlimDevices: Beta] Bug process, unconfirmed bugs ?
Philip Meyer;565955 Wrote: > >I think we should just publicize the "3 votes rule" as I don't think > >it's worth the trouble of manually confirming bugs. > Does this process really work though? > ... > So, even if there are 3 or more votes and the bug gets confirmed, there > appears to be little chance of it getting progressed any further. I agree. That's why I haven't bothered trying to confirm unconfirmed bugs lately. It seems to clearly be a waste of my time. All we have now is a negative rule: Logitech won't consider a bug from an outsider unless either 3 outsiders vote on that bug or one of us with canconfirm rights confirms it. With no commitment from Logitech to review confirmed bugs, why should I spend time confirming anything? I think Erland's on track with the "call support" suggestion. I don't know how Logitech prioritizes bugs, but I suspect they prioritize bugs that they believe cost them money. In theory this means bugs that result in lost sales, but I expect that mostly it means bugs that are triggering support calls (like 'this' (http://bugs.slimdevices.com/show_bug.cgi?id=16215#c3)). Providing details and patches in Bugzilla might be nice, and very helpful to developers, but I expect it's only the "'squeaky wheels' (http://www.urbandictionary.com/define.php?term=squeaky%20wheel%20gets%20the%20grease)" whose bugs get prioritized. I still report the bugs I see, and when I patch SBS on my system, I share the patch. But I no longer expect to get anything out of bugzilla. Also, Erland, you've written about the number of unconfirmed bugs. I think it's more troubling how many bugs there are that are targeted, prioritized, and assigned. I count '271 right now' (http://bugs.slimdevices.com/buglist.cgi?priority=P1;priority=P2;priority=P3;priority=P4;priority=P5;emailassigned_to1=1;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=RESOLVED;bug_status=VERIFIED;email1=%20unassigned%40slimdevices.com%20%20;resolution=---;target_milestone=7.5.x;target_milestone=7.6;target_milestone=7.6.0;target_milestone=7.7.0;known_name=prioritizedBugs;query_based_on=prioritizedBugs;emailtype1=notequals). Andy said there are 5 full-time developers working on Squeezebox, so perhaps they're so swamped with existing, prioritized bugs that they have no time left to investigate new ones. All the more reason, I fear, for keeping expectations low for bugzilla tickets. -- peterw http://www.tux.org/~peterw/ Free plugins: 'AllQuiet' (http://www.tux.org/~peterw/slim/AllQuiet.html) 'Auto Dim/AutoDisplay' (http://www.tux.org/~peterw/slim/AutoDisplay.html) 'BlankSaver' (http://www.tux.org/~peterw/slim/BlankSaver.html) 'ContextMenu' (http://www.tux.org/~peterw/slim/ContextMenu.html) 'DenonSerial' (http://www.tux.org/~peterw/slim/DenonSerial.html) 'FuzzyTime' (http://www.tux.org/~peterw/slim/FuzzyTime.html) 'KidsPlay' (http://www.tux.org/~peterw/slim/KidsPlay.html) 'KitchenTimer' (http://www.tux.org/~peterw/slim/KitchenTimer.html) 'PlayLog' (http://www.tux.org/~peterw/slim/PlayLog.html) 'PowerCenter/BottleRocket' (http://www.tux.org/~peterw/slim/PowerCenter.html) 'SaverSwitcher' (http://www.tux.org/~peterw/slim/SaverSwitcher.html) 'SettingsManager' (http://www.tux.org/~peterw/slim/SettingsManager.html) 'SleepFade' (http://www.tux.org/~peterw/slim/SleepFade.html) 'StatusFirst' (http://www.tux.org/~peterw/slim/StatusFirst.html) 'SyncOptions' (http://www.tux.org/~peterw/slim/SyncOptions.html) 'VolumeLock' (http://www.tux.org/~peterw/slim/VolumeLock.html) peterw's Profile: http://forums.slimdevices.com/member.php?userid=2107 View this thread: http://forums.slimdevices.com/showthread.php?t=80856 ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/beta
Re: [SlimDevices: Beta] Bug process, unconfirmed bugs ?
Philip Meyer;565955 Wrote:
>
> Some bug reports have a lot of votes. eg. bug 112 "sort albums by
> year". This bug is over 6 years old and has 61 votes!!!
>
> So, even if there are 3 or more votes and the bug gets confirmed, there
> appears to be little chance of it getting progressed any further.
>
The votes are just an indication that something is worth to consider.
If it's something that requires a lot of work or something that doesn't
follow the product strategy it might never be implemented even if it has
a lot of votes. It's easy to vote on an enhancement so it should be used
as a factor when prioritizing enhancements but it cannot be the main
factor unless a lot more users start to vote in bugzilla.
Browsing/statistics functions, playlists management and other features
that enhance how you select what to play are clearly not a prioritized
area within Logitech, as you know there are several very old
enhancements in this area on the top voted list. I personally still
don't understand why this area has so low priority since it's the most
important area to me.
--
erland
Erland Isaksson ('My homepage' (http://erland.isaksson.info))
(Developer of 'many plugins/applets'
(http://wiki.slimdevices.com/index.php/User:Erland). If my answer
helped you and you like to encourage future presence on this forum
and/or third party plugin/applet development, 'donations are always
appreciated' (http://erland.isaksson.info/donate))
erland's Profile: http://forums.slimdevices.com/member.php?userid=3124
View this thread: http://forums.slimdevices.com/showthread.php?t=80856
___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/beta
Re: [SlimDevices: Beta] Bug process, unconfirmed bugs ?
Philip Meyer;565952 Wrote:
> If I was a user who had gone to the bother of raising a bug, I'd be a
> bit miffed if I didn't get a response within say a couple of weeks.
> Even if it was an auto-reply "we acknowledge the receipt of your bug
> report, thank you".
>
> I wonder what the process is for support calls - how many calls are
> closed through telling the user that their issue is a (known/new) bug.
> Do support raise bugs when users report problems - are they confirmed by
> support?
>
> Support may be overwhelmed, but that's to be expected when there are
> 2615 open bug reports against the product (1738 if you ignore trivial
> and enhancement requests). That's an indication that there are
> problems that people will be experiencing and thus continually calling
> support about. Fix some bugs, and there may be be less support calls.
>
All this is the main reason why I'm starting to feel it might be better
to refer new users to the support instead of asking them to file a bug.
It will make Logitech support staff more aware of the problems users
have and if will result in faster feedback to the user an we can avoid
a lot of incomplete bug reports and duplicates in bugzilla.
At the moment it feels like we are "hiding" the problems in unconfirmed
bugs which also results in frustrated users who feels ignored. The
Logitech support staff might also not be aware of all the frustrated
users as long as they don't monitor these forums.
The situation for enhancement requests is a bit different, for
enhancements it feels like voting could be a good idea. Enhancement
requests with less than three votes are probably not worth to consider.
--
erland
Erland Isaksson ('My homepage' (http://erland.isaksson.info))
(Developer of 'many plugins/applets'
(http://wiki.slimdevices.com/index.php/User:Erland). If my answer
helped you and you like to encourage future presence on this forum
and/or third party plugin/applet development, 'donations are always
appreciated' (http://erland.isaksson.info/donate))
erland's Profile: http://forums.slimdevices.com/member.php?userid=3124
View this thread: http://forums.slimdevices.com/showthread.php?t=80856
___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/beta
Re: [SlimDevices: Beta] Bug process, unconfirmed bugs ?
>I think we should just publicize the "3 votes rule" as I don't think >it's worth the trouble of manually confirming bugs. Does this process really work though? How many people actually vote on bugs. It seems that individuals report the same issue on duplicate bug reports, and it seems it's now up to the community to detect those dups. The only chance for multiple votes is if the original supporter advertises the issue on the forums. Actually, I had a look at numbers of votes per bug report. There are 235 that have 3 or more votes. Every single one of them has a status of NEW. i.e. none of them are even assigned to be processed. Some bug reports have a lot of votes. eg. bug 112 "sort albums by year". This bug is over 6 years old and has 61 votes!!! So, even if there are 3 or more votes and the bug gets confirmed, there appears to be little chance of it getting progressed any further. ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/beta
Re: [SlimDevices: Beta] Bug process, unconfirmed bugs ?
If I was a user who had gone to the bother of raising a bug, I'd be a bit miffed if I didn't get a response within say a couple of weeks. Even if it was an auto-reply "we acknowledge the receipt of your bug report, thank you". I wonder what the process is for support calls - how many calls are closed through telling the user that their issue is a (known/new) bug. Do support raise bugs when users report problems - are they confirmed by support? Support may be overwhelmed, but that's to be expected when there are 2615 open bug reports against the product (1738 if you ignore trivial and enhancement requests). That's an indication that there are problems that people will be experiencing and thus continually calling support about. Fix some bugs, and there may be be less support calls. ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/beta
Re: [SlimDevices: Beta] rescan fails to find new muisc, 7.6.0 - r31134
same here, same server build on Mac OS 10.6.4, itunes music folder on an external volume (over firewire) If I'm correct there was last year a similar bug on the 7.5 beta... -- sbb sbb's Profile: http://forums.slimdevices.com/member.php?userid=14322 View this thread: http://forums.slimdevices.com/showthread.php?t=80821 ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/beta
Re: [SlimDevices: Beta] Bug process, unconfirmed bugs ?
I think we should just publicize the "3 votes rule" as I don't think it's worth the trouble of manually confirming bugs. There are a few things that can happen to a bug that should increase the likelihood of its being resolved/implemented: being confirmed, getting votes, being assigned, and being prioritized. In seems to me that the only one of those events that matters is being prioritized. I've seen confirmed bugs with dozens of votes lie dormant, I've seen assigned bugs with functional patches lie untouched. And I've watched customers expend lots of time & energy lobbying for significant patches to fix significant problems affecting many users, only to (apparently) feel frustrated in the end. I don't know what it takes to get a bug assigned a priority level, so I've pretty much given up trying to find bugs & bring them to Logitech's attention. I'll file bugs as I see them, but in the years I've used Squeezeboxes, never before has time spent in bugzilla felt so unrewarding. -- peterw http://www.tux.org/~peterw/ Free plugins: 'AllQuiet' (http://www.tux.org/~peterw/slim/AllQuiet.html) 'Auto Dim/AutoDisplay' (http://www.tux.org/~peterw/slim/AutoDisplay.html) 'BlankSaver' (http://www.tux.org/~peterw/slim/BlankSaver.html) 'ContextMenu' (http://www.tux.org/~peterw/slim/ContextMenu.html) 'DenonSerial' (http://www.tux.org/~peterw/slim/DenonSerial.html) 'FuzzyTime' (http://www.tux.org/~peterw/slim/FuzzyTime.html) 'KidsPlay' (http://www.tux.org/~peterw/slim/KidsPlay.html) 'KitchenTimer' (http://www.tux.org/~peterw/slim/KitchenTimer.html) 'PlayLog' (http://www.tux.org/~peterw/slim/PlayLog.html) 'PowerCenter/BottleRocket' (http://www.tux.org/~peterw/slim/PowerCenter.html) 'SaverSwitcher' (http://www.tux.org/~peterw/slim/SaverSwitcher.html) 'SettingsManager' (http://www.tux.org/~peterw/slim/SettingsManager.html) 'SleepFade' (http://www.tux.org/~peterw/slim/SleepFade.html) 'StatusFirst' (http://www.tux.org/~peterw/slim/StatusFirst.html) 'SyncOptions' (http://www.tux.org/~peterw/slim/SyncOptions.html) 'VolumeLock' (http://www.tux.org/~peterw/slim/VolumeLock.html) peterw's Profile: http://forums.slimdevices.com/member.php?userid=2107 View this thread: http://forums.slimdevices.com/showthread.php?t=80856 ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/beta
Re: [SlimDevices: Beta] 7.6 do not scan files beginning with "." in linux
I renamed the files some songs begin with ... But i kept the tag as is sbs can use tag's with ... -- Mnyb Main hifi: Touch + CIA PS +MeridianG68J MeridianHD621 and assorted amps SiriuS, Classe' Primare and Dynadio speakers, Contour 4 Contour Center, and Contour 1.3SE for the rear ch. Rel Stadium 3 sub. Bedroom/Office: Boom Kitchen: SB3 + powered Fostex PM0.4 Miscellaneous use: Radio (with battery) I use a Controller various ir-remotes and a Eee-PC with squeezeplay to control this Mnyb's Profile: http://forums.slimdevices.com/member.php?userid=4143 View this thread: http://forums.slimdevices.com/showthread.php?t=80855 ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/beta
Re: [SlimDevices: Beta] Bug process, unconfirmed bugs ?
Mnyb;565840 Wrote:
> many off these seems to be support cases ? could not support trawl BZ at
> least once a week ?
>
That would of course be good but I suspect they are also loaded with
work and probably want to focus on answering support cases related to
people that contacts them instead of trying to find new support cases
through bugzilla.
The problem for the support team is probably also that in bugzilla they
don't have enough information about the user to start a support case,
they basically just have an e-mail address. I think the support team
probably like a to have a phone number they can use to directly contact
the user since direct contact often is needed to solve many support
issues.
I wonder if it would be preferred if bugs in bugzilla only was reported
by:
1. Logitech employees
2. Senior community members which typically knows how to verify that
the problem is real and provides enough structured information and
knows how to search bugzilla for duplicates before registering a new
bug. They could also typically have canconfirm permission so the bugs
gets confirmed immediately, shouldn't be a problems that these users
have confirm permissions.
3. Enhancement requests from any community members and these would be
confirmed only through votes, so any enhancement request that doesn't
have at least 3 votes wouldn't have to be touched by Logitech.
And all other users with problems, would requested to search bugzilla
and vote for bugs they have or contact support if they believe they
have a problem that doesn't exist in bugzilla.
The difference compared to today would basically be that we wouldn't
recommend new users to register a bug we would only recommend them to
contact support or search bugzilla for existing bugs. The result would
be that unconfirmed bugs would only be:
- Enhancement requests which not enough users are interested in
- Bugs reported by new users who have decided to not follow our advice
to contact the Logitech support team.
At regular interval we could go through unconfirmed bugs which aren't
marked as enhancements and recommend the reporting user to contact
Logitech support to get their problem solved or get a confirmation of
the bug.
Would this work or would it be too extreme ?
--
erland
Erland Isaksson ('My homepage' (http://erland.isaksson.info))
(Developer of 'many plugins/applets'
(http://wiki.slimdevices.com/index.php/User:Erland). If my answer
helped you and you like to encourage future presence on this forum
and/or third party plugin/applet development, 'donations are always
appreciated' (http://erland.isaksson.info/donate))
erland's Profile: http://forums.slimdevices.com/member.php?userid=3124
View this thread: http://forums.slimdevices.com/showthread.php?t=80856
___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/beta
Re: [SlimDevices: Beta] Bug process, unconfirmed bugs ?
Mark Miksis;565838 Wrote:
> Erland,
>
> I don't disagree with your concerns, but FYI. Note that the burden to
> confirm bugs doesn't rely solely with those of us who have CANCONFIRM
> permission. A bug that receives 3 votes from ANY BZ users will
> automatically become confirmed.
>
Thanks, I added this to my initial post.
--
erland
Erland Isaksson ('My homepage' (http://erland.isaksson.info))
(Developer of 'many plugins/applets'
(http://wiki.slimdevices.com/index.php/User:Erland). If my answer
helped you and you like to encourage future presence on this forum
and/or third party plugin/applet development, 'donations are always
appreciated' (http://erland.isaksson.info/donate))
erland's Profile: http://forums.slimdevices.com/member.php?userid=3124
View this thread: http://forums.slimdevices.com/showthread.php?t=80856
___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/beta
Re: [SlimDevices: Beta] 7.6 do not scan files beginning with "." in linux
Files beginning with a . are hidden files in linux. So ignoring those files is correct behavior. -- qball qball's Profile: http://forums.slimdevices.com/member.php?userid=32031 View this thread: http://forums.slimdevices.com/showthread.php?t=80855 ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/beta
Re: [SlimDevices: Beta] Bug process, unconfirmed bugs ?
many off these seems to be support cases ? could not support trawl BZ at least once a week ? -- Mnyb Main hifi: Touch + CIA PS +MeridianG68J MeridianHD621 and assorted amps SiriuS, Classe' Primare and Dynadio speakers, Contour 4 Contour Center, and Contour 1.3SE for the rear ch. Rel Stadium 3 sub. Bedroom/Office: Boom Kitchen: SB3 + powered Fostex PM0.4 Miscellaneous use: Radio (with battery) I use a Controller various ir-remotes and a Eee-PC with squeezeplay to control this Mnyb's Profile: http://forums.slimdevices.com/member.php?userid=4143 View this thread: http://forums.slimdevices.com/showthread.php?t=80856 ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/beta
Re: [SlimDevices: Beta] Bug process, unconfirmed bugs ?
Erland, I don't disagree with your concerns, but FYI. Note that the burden to confirm bugs doesn't rely solely with those of us who have CANCONFIRM permission. A bug that receives 3 votes from ANY BZ users will automatically become confirmed. -- Mark Miksis Mark Miksis's Profile: http://forums.slimdevices.com/member.php?userid=529 View this thread: http://forums.slimdevices.com/showthread.php?t=80856 ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/beta
[SlimDevices: Beta] Bug process, unconfirmed bugs ?
As mentioned in another thread a while ago, the list of unconfirmed bugs
are starting to get pretty huge and I'm starting to get a bit worried if
no one at Logitech looks as these.
So some questions:
1.
How do we handle bugs that really should be support issues ?
I have permission to change unconfirmed bugs status to NEW or ASSIGNED
but none of them seems appropriate for stuff that should be handled by
the support staff ?
I'd really just like to ask the reporter to contact support and get rid
of them from the list so it's easier to do a search that only includes
unconfirmed bugs that haven't been looked at yet.
2.
How do we handle unconfirmed bugs that have been assigned to Logitech
employees, can these just be ignored by community resources confirming
bugs ?
I thought the idea was that Logitech developers shouldn't be bothered
with bugs until they are confirmed, but I suppose they might just be
helping the QA team to confirm bugs in these cases ? Or is this some
indication that the confirm process doesn't work ?
3.
Is there anyone at Logitech that have the time to go through the
unconfirmed bugs and try to confirm them or is this totally up to the
community and Logitech will only focus on its internal testing ?
I'm asking since there are number of bugs with severity "Critical" and
"Blocker" that has been unconfirmed for months. If there is no one at
Logitech that at least have the time to go through those that are
"Critical" and "Blocker" it feels like we are ignoring users with big
problems.
4.
Since the list of unconfirmed bugs seems to be pretty huge, I'm a bit
worried that the community isn't able to handle the confirmation
process and in that case it kind of feels like it might be better to
ask users with problem to contact Logitech support than asking them to
register a bug for a problem they have. If they just register a bug and
it just stays unconfirmed, it kind of feels like none is taking their
problem seriously. In this case it would probably be better if they
contacted the support staff that could register a confirmed bug for
them with all the information needed. Would it be better if we asked
users to contact Logitech support when they find bugs which no senior
member can easily confirm immediately ?
As a community member, my spare time is limited, which means that I
can't justify spending time confirming bugs that I can't easily confirm
without totally reconfiguring my setup or re-tagging my music. The
situation might have been differently if the Logitech test team was
more visible on these forums, so it at least felt like someone
appreciated what I did, but this isn't the case at the moment. I'm
guessing the reason is that they need to focus on their internal
testing with the limited number of resources they probably have access
to.
To any senior member reading this post:
- If you like to help finding duplicates, go though the unconfirmed
list and add comments with a link in any bugs that you feel is a
duplicate of some other bug. If anyone knows that there is some special
syntax we should use for marking duplicates, please let us know.
- If you like to help confirming but don't have permission to confirm
bugs, could you at least go through the bugs you want to confirm and
add a comment in those you have reproduced in your own setup. This way,
those of us with confirm permissions, can focus on verifying that the
bugs have enough information and don't have to spend time reproducing
them.
- If you like to help and want to get confirm permission, continue
reading in this thread:
http://forums.slimdevices.com/showthread.php?p=505545#post505545
The current list of unconfirmed bugs can be found here:
http://bugs.slimdevices.com/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED
The bug process can be found here:
http://forums.slimdevices.com/showthread.php?t=74846
(There is an incorrect https link in the bug process post by the way,
so maybe someone with permission could correct that to a http link)
I suspect that if all senior members would go through this list and
confirm one or a few bugs each we could shrink the list of unconfirmed
bugs pretty fast.
--
erland
Erland Isaksson ('My homepage' (http://erland.isaksson.info))
(Developer of 'many plugins/applets'
(http://wiki.slimdevices.com/index.php/User:Erland). If my answer
helped you and you like to encourage future presence on this forum
and/or third party plugin/applet development, 'donations are always
appreciated' (http://erland.isaksson.info/donate))
erland's Profile: http://forums.slimdevices.com/member.php?userid=3124
View this thread: http://forums.slimdevices.com/showthread.php?t=80856
___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/beta
[SlimDevices: Beta] 7.6 do not scan files beginning with "." in linux
7.6 do not scan files beginning with "." in linux Is this by design or is it a bug . .blabla usually means that it is "hidden" in linux but thats not stopping any application to find it ? -- Mnyb Main hifi: Touch + CIA PS +MeridianG68J MeridianHD621 and assorted amps SiriuS, Classe' Primare and Dynadio speakers, Contour 4 Contour Center, and Contour 1.3SE for the rear ch. Rel Stadium 3 sub. Bedroom/Office: Boom Kitchen: SB3 + powered Fostex PM0.4 Miscellaneous use: Radio (with battery) I use a Controller various ir-remotes and a Eee-PC with squeezeplay to control this Mnyb's Profile: http://forums.slimdevices.com/member.php?userid=4143 View this thread: http://forums.slimdevices.com/showthread.php?t=80855 ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/beta
Re: [SlimDevices: Beta] 7.6: linkin to other drives not workin anymore?
hmm...also only would know how to mount a whole drive / device to a directory of choice somewhere. Cant find anything on mounting just directories...to my knowledge that's what they have linkin for. Thx for all the input here - did try to find some bug like this in bugzilla but couldnt find one so entered a new now. Easy way to reproduce error btw: Just go to directory where the linked dir is located in (doesnt matter if it's web-interface or duet), then try to enter the linked dir. It will shortly kinda "flicker" and then show the directory the linked dir is located in again. If you try that a couple of times, you will have to press "back" to get back out of that base dir also a couple of times plus one. As I said 7.5.2 definitely makes it work again while 7.6 def. breaks it again. I think there was a thread here with "double scanned files" due to links in scanned directories linkin to other directories that were also included in library scan already anyways. Perhaps that behaviour is a "side-effect" of a try to fix that? People just using the system differently def. doesnt make it easier for the developers I fear ;). @pfarrell: you can reproduce the behaviour I have for your cds with your linked dir? sounds like it could be the same... -- RaF93 --- RaF93 also on last.fm RaF93's Profile: http://forums.slimdevices.com/member.php?userid=17170 View this thread: http://forums.slimdevices.com/showthread.php?t=80640 ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/beta
Re: [SlimDevices: Beta] 7.6: linkin to other drives not workin anymore?
Hmm wonder if this issue could be bypassed by actually mount that drive or directory in the music path ? I know how to mount a drive anywhere, but is linux capable of mounting a specific dir from a drive to a place you choose ? -- Mnyb Main hifi: Touch + CIA PS +MeridianG68J MeridianHD621 and assorted amps SiriuS, Classe' Primare and Dynadio speakers, Contour 4 Contour Center, and Contour 1.3SE for the rear ch. Rel Stadium 3 sub. Bedroom/Office: Boom Kitchen: SB3 + powered Fostex PM0.4 Miscellaneous use: Radio (with battery) I use a Controller various ir-remotes and a Eee-PC with squeezeplay to control this Mnyb's Profile: http://forums.slimdevices.com/member.php?userid=4143 View this thread: http://forums.slimdevices.com/showthread.php?t=80640 ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/beta
