PDA

View Full Version : VortexBox 7.6.1 FAST! (sort-of)



pski
2011-09-02, 11:35
I cloned my live server (after moving the players to my backup server) and used the web interface to update VB.

No errors reported.

Rescan results:

1. discovering files/directories 27212 in 52 seconds (Wow!)
2. scanning new files 23756 in 19:24 (Wow!)
3. pre-caching arwork 1888 of 1908 in 17:08:00 and counting (WOW! - only seventeen HOURS to do 99%. Something tells me it's going to take a little more than 10.2 minutes to do the rest...)

Something else tells me if I abort the scan and restart the machine, it's going to do the exact same thing again !

1 gig memory, two processors at 2.5Ghz, 5023 bogomips. CPU is between 50-58%. The account is mounted as NFS.

P

Ron Olsen
2011-09-02, 13:10
If you want faster scanning performance, install a 2 TB SATA drive in your VB and use it for your music library instead of a NFS network drive.

SBS 7.6.1 works very well on my VortexBox Appliance with this setup. Scanning times are significantly faster than with SBS 7.5.x.

dsdreamer
2011-09-02, 14:50
If you want faster scanning performance, install a 2 TB SATA drive in your VB and use it for your music library instead of a NFS network drive.

SBS 7.6.1 works very well on my VortexBox Appliance with this setup. Scanning times are significantly faster than with SBS 7.5.x.

Ron, it looks as if you were speed-reading the OP's remarks. Pski is really complaining that the 7.6.1 scanner is not capable of processing certain of his artwork files and instead of skipping them with a warning it hangs or dies in an uncontrolled way.

pski
2011-09-02, 15:14
If you want faster scanning performance, install a 2 TB SATA drive in your VB and use it for your music library instead of a NFS network drive.

SBS 7.6.1 works very well on my VortexBox Appliance with this setup. Scanning times are significantly faster than with SBS 7.5.x.

The music scan part seems to be about 10-15 minutes faster in 7.6.1, but the rest is broken.

I use 2TB Samsungs in a ThermalTake toaster hooked to a eSata PCI-express card on my "movie machine." Vastly superior to any USB attach. Alas, the TeraStation Pro's are raid-5 and attached to a pure gigabit loop so with full-duplex and jumbo frames, their performance is very adequate as the music store.

I use VortexBox precisely because the webUI and scanning are so dramatically faster than winders. No VortexBox appliance is involved, only VB virtual machines running in VMWare Workstation.

P

pski
2011-09-03, 18:11
The SBS "finished" scanning but the settings/information screen says the time is keeping a long count. (37 hours, eh?)

Who is in charge?

P

pski
2011-09-03, 18:23
Ron, it looks as if you were speed-reading the OP's remarks. Pski is really complaining that the 7.6.1 scanner is not capable of processing certain of his artwork files and instead of skipping them with a warning it hangs or dies in an uncontrolled way.

Mostly, if what you say is true, certain artwork was not an issue earlier so I'm not sure why it would be now.

P

pski
2011-09-03, 18:38
So, since it only costs time, here's what a simple/default/rescan looks like

Ron Olsen
2011-09-03, 18:38
Mostly, if what you say is true, certain artwork was not an issue earlier so I'm not sure why it would be now.

P

VortexBox works best with a cover.jpg in each album directory; my VBA with SBS 7.6.1 has no trouble scanning this artwork.

What artwork are you using, if not a cover.jpg in each album directory?

Which artwork of yours is causing trouble?

pski
2011-09-03, 18:45
VortexBox works best with a cover.jpg in each album directory; my VBA with SBS 7.6.1 has no trouble scanning this artwork.

What artwork are you using, if not a cover.jpg in each album directory?

Which artwork of yours is causing trouble?

As you say, cover.jpg is in each folder. There is no indication of any artwork causing an error. The scanner log has warnings about resizeing but no indication of the file or a hard error. I have also enabled the debug settings pertinent to logging scanning. No help or hard error. Of course, I'm used to scanning running for a couple of DAYS but normally, that's the kind of thing I'm expected to fix.

Duh? Which artwork?

slate
2011-09-04, 00:09
Mostly, if what you say is true, certain artwork was not an issue earlier so I'm not sure why it would be now.

P

Well beside the shift to use SQLite for artwork handling; there were also code changes made about a year back.
Andy's details here http://forums.slimdevices.com/showthread.php?t=82087

All the changes gave a massive scan performance boost in my setup. You can see my result in post 6 and remember at that time the SQLite artwork handling had been around for a while; so the improvement that I report is only for the code changes.

Anyway the changes also seems to have made it more sensible to various dodgy issues that worked before; some caused the scanner to silently chrash and/or seems to run forever

I tried to compile a small report here http://forums.slimdevices.com/showpost.php?p=653428&postcount=16

pski
2011-09-04, 13:13
So, I made a new VM using the a new downloaded ISO from vortexbox.org. 7.6.1 from 22 Aug

Scanned files in 19 seconds
Scanned new files in 19:16
Pre-caching did 1899 of 1908 in three minutes. The time is still incrementing.

P

19 hours and 50 minutes: still pre-caching

26 hours and 22 minutes: still pre-caching

33 hours and 05 minutes: still pre-caching

pski
2011-09-07, 20:22
So, I made a new VM using the a new downloaded ISO from vortexbox.org. 7.6.1 from 22 Aug

THEN, I used the webUI to upgrade: 49 packages changed

Scanned files in 45 seconds
Scanned new files in 19:16
Pre-caching did 1881 of 19:10 in three minutes. The time is still incrementing.

JJZolx
2011-09-07, 20:30
> Pre-caching did 1881 of 19:10 in three minutes. The time is still
> incrementing.

1881 of 1910?

Is it stuck at 1881? Otherwise I'd expect it to complete in a few seconds.

Have you enable artwork debugging yet?

pski
2011-09-08, 12:56
> Pre-caching did 1881 of 19:10 in three minutes. The time is still
> incrementing.

1881 of 1910?

Is it stuck at 1881? Otherwise I'd expect it to complete in a few seconds.

Have you enable artwork debugging yet?

Ok, here's the bottom of the log with debug set:

0204] Slim::Utils::GDResizer::_cache (516) Warning: Cached music/c14c5243/cover_64x64_m (1980 bytes)
[11-09-08 15:47:58.0208] Slim::Utils::GDResizer::_cache (516) Warning: Cached music/c14c5243/cover_50x50_o (1672 bytes)
[11-09-08 15:47:58.0211] Slim::Utils::GDResizer::_cache (516) Warning: Cached music/c14c5243/cover_41x41_m (1353 bytes)
[11-09-08 15:47:58.0214] Slim::Utils::GDResizer::_cache (516) Warning: Cached music/c14c5243/cover_40x40_m (1282 bytes)
[11-09-08 15:47:58.0227] Slim::Music::Artwork::__ANON__ (515) Pre-caching artwork for Travel Log from /storage/ts1/music/paul/mp3/JJ Cale/JJ Cale - Travel log/13 - Humdinger.mp3
[11-09-08 15:47:58.0231] Slim::Utils::GDResizer::resizeSeries (225) Warning: Resizing series: 100x100
[11-09-08 15:47:58.0741] Slim::Utils::GDResizer::_read_tag (253) Warning: Reading tags from audio file...
[11-09-08 15:47:58.0897] Slim::Utils::GDResizer::_read_tag (314) Warning: Offset information not found, re-reading file for direct artwork
[11-09-08 15:47:58.0955] Slim::Utils::GDResizer::resize (161) Warning: Resizing from 200x200 jpg @ to 100xX

Is the output log buffered? Is it possible that tail isn't showing the true end of what the scanner has done?

In the webUI, both the song and the album have artwork. The "album" reported in the status had artwork imbedded in each song according to mp3tag. I have removed it and will try to kill this scan and retry.

JJZolx
2011-09-08, 13:21
[11-09-08 15:47:58.0227] Slim::Music::Artwork::__ANON__ (515) Pre-caching artwork for Travel Log from /storage/ts1/music/paul/mp3/JJ Cale/JJ Cale - Travel log/13 - Humdinger.mp3
[11-09-08 15:47:58.0231] Slim::Utils::GDResizer::resizeSeries (225) Warning: Resizing series: 100x100
[11-09-08 15:47:58.0741] Slim::Utils::GDResizer::_read_tag (253) Warning: Reading tags from audio file...
[11-09-08 15:47:58.0897] Slim::Utils::GDResizer::_read_tag (314) Warning: Offset information not found, re-reading file for direct artwork
11-09-08 15:47:58.0955] Slim::Utils::GDResizer::resize (161) Warning: Resizing from 200x200 jpg @ to 100xX


So it gets stuck there and you get no more scanner log output?

Andy, any idea what the bug is here?

pski
2011-09-08, 14:44
[11-09-08 15:47:58.0227] Slim::Music::Artwork::__ANON__ (515) Pre-caching artwork for Travel Log from /storage/ts1/music/paul/mp3/JJ Cale/JJ Cale - Travel log/13 - Humdinger.mp3
[11-09-08 15:47:58.0231] Slim::Utils::GDResizer::resizeSeries (225) Warning: Resizing series: 100x100
[11-09-08 15:47:58.0741] Slim::Utils::GDResizer::_read_tag (253) Warning: Reading tags from audio file...
[11-09-08 15:47:58.0897] Slim::Utils::GDResizer::_read_tag (314) Warning: Offset information not found, re-reading file for direct artwork
11-09-08 15:47:58.0955] Slim::Utils::GDResizer::resize (161) Warning: Resizing from 200x200 jpg @ to 100xX


So it gets stuck there and you get no more scanner log output?

Andy, any idea what the bug is here?

So true. After removing the embedded artwork in the last album reported, a clear and rescan only got to 1858 of 1910..

settings/information/"abort scan" seems to have no effect.

P

Make that "HAS NO EFFECT."

mherger
2011-09-08, 21:02
> So true. After removing the embedded artwork in the last album
> reported, a clear and rescan only got to 1858 of 1910..

Could you please send me a copy of the file with the artwork? I'd like to reproduce this. michael št slimdevices dot com

--

Michael

pski
2011-09-09, 15:41
> So true. After removing the embedded artwork in the last album
> reported, a clear and rescan only got to 1858 of 1910..

Could you please send me a copy of the file with the artwork? I'd like to reproduce this. michael št slimdevices dot com

--

Michael

Do you want the "last reported" album on the scan status or the last mentioned file/album contents in the scan log?

P

Ron Olsen
2011-09-09, 16:12
If I were facing your problem, I would delete ALL embedded artwork in ALL music files in my SBS library, and just use a cover.jpg file in each album directory. Then do a "clear library and rescan everything".

pski
2011-09-09, 16:24
If I were facing your problem, I would delete ALL embedded artwork in ALL music files in my SBS library, and just use a cover.jpg file in each album directory. Then do a "clear library and rescan everything".

Thanks, Ron, That's been my policy since I started using SqueezeCenter. If there's a one-step way to remove all the embedded, I'm all ears.

Only recently I started with MP3Tag because even with cover.jpg, some albums did not show artwork.

Thanks for the "were." I mourn the death of the subjunctive.

P

JJZolx
2011-09-09, 16:37
Thanks, Ron, That's been my policy since I started using SqueezeCenter. If there's a one-step way to remove all the embedded, I'm all ears.

Only recently I started with MP3Tag because even with cover.jpg, some albums did not show artwork.

It's easy to do in Mp3tag. You can use a 'quick' action or create a saved action group. Use a 'Remove fields' type of action and designate PICTURE as the field name. There's also an 'Export cover to file' action if you need to save the cover first.

(So does this mean that there's solid evidence that the extremely slow artwork scanning that many people are experiencing is due to problems that 7.6 is having with embedded images? Please make sure you send some of the suspect files to Logitech so that they can figure out what's wrong.)

pski
2011-09-09, 16:45
It's easy to do in Mp3tag. You can use a 'quick' action or create a saved action group. Use a 'Remove fields' type of action and designate PICTURE as the field name. There's also an 'Export cover to file' action if you need to save the cover first.

(So does this mean that there's solid evidence that the extremely slow artwork scanning that many people are experiencing is due to problems that 7.6 is having with embedded images? Please make sure you send some of the suspect files to Logitech so that they can figure out what's wrong.)

see my previous response to you. I have no evidence of a cause except that removing some embedded artwork changes the number of pre-cached albums processed. Especially, I have no direct evidence that my changes to embedded artwork are causative.

P

JJZolx
2011-09-09, 16:54
see my previous response to you. I have no evidence of a cause except that removing some embedded artwork changes the number of pre-cached albums processed. Especially, I have no direct evidence that my changes to embedded artwork are causative.

I was asking more for a collective opinion. I realize that you haven't really figured it out yet. If you remove all embedded artwork, though, and then SBS pre-caches artwork at a normal rate, I'd say that pretty much tells us what was wrong on your system. Let us know.

pski
2011-09-10, 17:40
I was asking more for a collective opinion. I realize that you haven't really figured it out yet. If you remove all embedded artwork, though, and then SBS pre-caches artwork at a normal rate, I'd say that pretty much tells us what was wrong on your system. Let us know.

Remove all embedded artwork. OK. How?

"It's easier said than done !"

P

Ron Olsen
2011-09-10, 18:01
Remove all embedded artwork. OK. How?

"It's easier said than done !"

P

Found this by Googling "mp3tag remove embedded artwork action":

http://forums.mp3tag.de/index.php?showtopic=4043

pski
2011-09-10, 18:38
Found this by Googling "mp3tag remove embedded artwork action":

http://forums.mp3tag.de/index.php?showtopic=4043

And your test?

P

Ron Olsen
2011-09-10, 23:12
And your test?

P

I have no test. I was trying to help you find information that would help you solve your problem.

I have never used mp3tag to batch remove embedded cover art. I've just done it manually, a folder at a time:

1. Navigate mp3tag to a folder in which you want to remove embedded cover art.
2. Select all files.
3. Right click on the cover art box.
4. Select Remove Cover.
5. Click Save.

Embedded cover art is removed from all selected files.

garym
2011-09-11, 17:45
I have no test. I was trying to help you find information that would help you solve your problem.

I have never used mp3tag to batch remove embedded cover art. I've just done it manually, a folder at a time:

1. Navigate mp3tag to a folder in which you want to remove embedded cover art.
2. Select all files.
3. Right click on the cover art box.
4. Select Remove Cover.
5. Click Save.

Embedded cover art is removed from all selected files.

I've done this in batch mode. Open your top level music directory in mp3tag. After all files are loaded, select all. Then right click and choose extended tags. In right pane is an X for deleting embeded album art. Click on it then save files. Done! You can also use an action in mp3tag to create a cover.jpg file within each subdirectory by reading the embedded art. You would obviously want to do this step first.

pski
2011-09-13, 16:11
I've done this in batch mode. Open your top level music directory in mp3tag. After all files are loaded, select all. Then right click and choose extended tags. In right pane is an X for deleting embeded album art. Click on it then save files. Done! You can also use an action in mp3tag to create a cover.jpg file within each subdirectory by reading the embedded art. You would obviously want to do this step first.

Thanks, garym

I removed all inbred artwork and the scan completes now. All my folders already have cover.jpg.

P

garym
2011-09-13, 16:13
Thanks, garym

I removed all inbred artwork and the scan completes now. All my folders already have cover.jpg.

P

Perfect. I finally made the decision to remove all my embedded art in FLAC files and use cover.jpg, particularly since I've been adding larger artwork for my ipad stuff. Worked well!

Mnyb
2011-09-13, 21:05
I have a lot of embedded art (almost all of it) , without experiencing problems ?
Then of course it is the case with multiple embedded arts, which are hard to tell .

I will stick to embedded (and folder.jpg) until I crash and burn , can't have to smooth collection if I'm going to beta test with it ;)

Besides I like the files to be self sufficient out of album and sbs context.

Ron Olsen
2011-09-13, 22:32
I have a lot of embedded art (almost all of it) , without experiencing problems ?
Then of course it is the case with multiple embedded arts, which are hard to tell .

I will stick to embedded (and folder.jpg) until I crash and burn , can't have to smooth collection if I'm going to beta test with it ;)

Besides I like the files to be self sufficient out of album and sbs context.

I'm glad you are not having problems with embedded art. No need to change anything if it's working as is.

However, other users have had problems traceable to embedded art, and may benefit by removing it.

I run on VortexBox 1.10, and use its built-in software to mirror my FLAC library to mp3.

I do NOT embed art in the FLAC files, and use a cover.jpg fike in each album directory.

I have the mp3 mirror embed the cover.jpg in each mp3 file, however.
I then add these mp3s to my iTunes library (running on a Mac).

So while there is no need to have cover art embedded in files managed by SBS, there certainly is reason to embed art in files managed by iTunes.

garym
2011-09-14, 03:30
I'm glad you are not having problems with embedded art. No need to change anything if it's working as is.

However, other users have had problems traceable to embedded art, and may benefit by removing it.

I run on VortexBox 1.10, and use its built-in software to mirror my FLAC library to mp3.

I do NOT embed art in the FLAC files, and use a cover.jpg fike in each album directory.

I have the mp3 mirror embed the cover.jpg in each mp3 file, however.
I then add these mp3s to my iTunes library (running on a Mac).

So while there is no need to have cover art embedded in files managed by SBS, there certainly is reason to embed art in files managed by iTunes.

+1, I've removed embedded art from my FLACs, but still use embedded art in my mirror mp3 files for the iphone/ipods.

p.s. mnyb, I never actually had a single problem with embedded art in my FLACs in any version of SbS I've used, including 7.6.1.

Mnyb
2011-09-14, 06:38
Point I trying to make is that it might not be the embedding that is the problem, but the art one has embedded ?

But if you have 100000 flac files where to start fixing ?? Especially with more than one art in each file

Remove the lot seems to be the best solution then.

garym
2011-09-14, 06:39
Point I trying to make is that it might not be the embedding that is the problem, but the art one has embedded ?


true, my embedded art was never a problem, but I know for sure it was always .jpg format, and nothing super large.

Ron Olsen
2011-09-14, 07:08
Point I trying to make is that it might not be the embedding that is the problem, but the art one has embedded ?

But if you have 100000 flac files where to start fixing ?? Especially with more than one art in each file

Remove the lot seems to be the best solution then.

I agree that there must be some specific embedded art that is causing the problem, and not embedding per se.

However, even with debug logging turned on, it seems difficult to figure out which specific files are causing problems.

Hence the suggestion to remove all embedded art.

The goal is to fix the scanning problem, not to identify the files that cause problems.

slate
2011-09-14, 07:19
Got to think about this post from AudioAudi about his fight with artwork
http://forums.slimdevices.com/showthread.php?t=89789

pski
2011-09-16, 17:25
OK:

After removing all the inbred artwork at using mp3tag to change all the 2011 albums to 2011 (to "fix" New Music,) VB 7.6.1 of 22 Aug cleared and scanned 27282 and 1915 albums in 20:33.

This is in VMWorkstation 6.5 on an AMD (Compaq CQ5110Y Athlon Dual-core 7550 at 2.5GHz host running Vista Ultimate and 3GB of memory) VM given 2 processors and 1 GB of memory.

All the music is on a TeraStation Pro and the network is pure 1GB (with full duplex and jumbo frames enabled.)

The previous server was a 3GB Dual-core 2.8GHz running Vista Business. That server took more than an hour longer for a full scan and the response of the webUI is startling faster.

Why all the grief? Why isn't there an option to IGNORE inbred artwork?

P

Ron Olsen
2011-09-16, 17:32
OK:
Why all the grief? Why isn't there an option to IGNORE inbred artwork?


Because it hasn't been implemented, and I don't recall anyone asking for this feature before your post. If SBS 7.6.1 could handle embedded artwork properly, and not choke when it encountered a problem, the feature wouldn't be needed. Maybe you should file an enhancement request in Bugzilla.

Glad you have things working now.

JJZolx
2011-09-16, 17:42
Why all the grief? Why isn't there an option to IGNORE inbred artwork?

Well, that's two different questions.

1. To answer the first, it's because there is a major BUG in the handling of embedded artwork. Which, apparently, nobody is any closer to figuring out.

2. As to the second question, I've asked the same thing myself. The plan for artwork is that embedded artwork could be used for individual track art (for the five or six people on the planet who care about such things), while cover/folder.jpg files would always be used for album artwork.

This is the bug report that is a catch all for the rework of artwork handling planned sometime in the future. See my comment #26.

http://bugs.slimdevices.com/show_bug.cgi?id=9919



To reinforce the need for an option to disable the scanning of embedded artwork, see the following forum discussion:

http://forums.slimdevices.com/showthread.php?t=79066

Some people have libraries in which they must embed artwork for other applications (such as iTunes), but they also provide separate cover/folder.jpg images. All that scanning and resizing the embedded images does is slow down their library scans.

JJZolx
2011-09-16, 17:46
Because it hasn't been implemented, and I don't recall anyone asking for this feature before your post. If SBS 7.6.1 could handle embedded artwork properly, and not choke when it encountered a problem, the feature wouldn't be needed. Maybe you should file an enhancement request in Bugzilla.

See my comment above and in the bug report.

Even if it worked properly for everyone, there's no _reason_ to scan embedded images when you have cover.jpg files.

pski
2011-09-16, 19:33
See my comment above and in the bug report.

Even if it worked properly for everyone, there's no _reason_ to scan embedded images when you have cover.jpg files.

+1

Also, it's putting my SB3 off instead of to sleep and why can't it remember I want to see "Large artwork?"

SMF

P

Ron Olsen
2011-09-16, 23:01
See my comment above and in the bug report.

Even if it worked properly for everyone, there's no _reason_ to scan embedded images when you have cover.jpg files.
Thanks for the pointer to the bug report.

I agree, proper cover art handling by SBS, that satisfies a wide range of user needs, requires a number of well-thought-out options, one of which you enumerate above.

Looking at the bug report, there's been a lot of discussion but no consensus, and nothing is scheduled to be changed in the 7.x timeframe (8.0.0 target milestone).

So it seems that the best strategy to ensure proper handling of art by SBS 7.6.1 is to remove all embedded art work and use cover.jpg in the album directory.

This conclusion likely holds for all versions of SBS in the 7.x series as well.

Mnyb
2011-09-17, 00:19
Thanks for the pointer to the bug report.

I agree, proper cover art handling by SBS, that satisfies a wide range of user needs, requires a number of well-thought-out options, one of which you enumerate above.

Looking at the bug report, there's been a lot of discussion but no consensus, and nothing is scheduled to be changed in the 7.x timeframe (8.0.0 target milestone).

So it seems that the best strategy to ensure proper handling of art by SBS 7.6.1 is to remove all embedded art work and use cover.jpg in the album directory.

This conclusion likely holds for all versions of SBS in the 7.x series as well.

Unless you have an album who is meant to have different art per track.
I have only one such album, I've got no clue on how common they are.

( Or wants to use single files by themselves outside SBS context, but thats off topic as this was about ensuring god artwork handling by SBS ).

Anyone figured this , would the scanner barf at a certain artwork if embedded but not as a separate file, can some version of tagging software muck up the embedding and produce such files that crashes the scanner ?

pski
2011-09-18, 18:44
Unless you have an album who is meant to have different art per track.
I have only one such album, I've got no clue on how common they are.

( Or wants to use single files by themselves outside SBS context, but thats off topic as this was about ensuring god artwork handling by SBS ).

Anyone figured this , would the scanner barf at a certain artwork if embedded but not as a separate file, can some version of tagging software muck up the embedding and produce such files that crashes the scanner ?

You apologize for a fault that was not previously seen. While I am not so accomplished, I've been using this for a few years.

Have you ever seen the phrase "It just works?"

SB products started as brilliant and got better <until recently>

Why is it that Touch has not been adapted and sold as an automotive solution? >with wi-fi it could sync from the house if y'all could get power control as a concept.)

P

JJZolx
2011-09-18, 19:31
Why is it that Touch has not been adapted and sold as an automotive solution? >with wi-fi it could sync from the house if y'all could get power control as a concept.)

Because there are already automotive computer solutions that are far more versatile than any Touch would be. Most in-dash devices use larger 7" touchscreens, and even larger screens are possible if mounted elsewhere. Most systems can incorporate not only music playback, but GPS based navigation and mapping, display of auto gauges and sensors, the ability to play DVDs, play games, display backup cameras, integrate with cellphones. Syncing a library via wifi is possible, but wifi reception from a device inside a vehicle can be poor, so ideally requires an external antenna.

toby10
2011-09-19, 04:17
..... Why is it that Touch has not been adapted and sold as an automotive solution? >with wi-fi it could sync from the house if y'all could get power control as a concept.....

SqueezeBox is already a niche product when used for it's intended purpose, home audio. SqueezeBox in an automobile environment would be of interest to only a minuscule few enthusiasts, if that.
Besides, the last thing we need is for Logitech to get any more distracted from the SqueezeBox core functionality. ;)

Mnyb
2011-09-19, 04:43
You apologize for a fault that was not previously seen. While I am not so accomplished, I've been using this for a few years.

Have you ever seen the phrase "It just works?"

SB products started as brilliant and got better <until recently>

Why is it that Touch has not been adapted and sold as an automotive solution? >with wi-fi it could sync from the house if y'all could get power control as a concept.)

P

That whas not what i meant I'm with you , I'm just puzzled as why it does not "just works" if a specific cause could be found someone could notify the devs .

It's a lottery your number was up, It seems like every scanner rewrite breaks it for a different subset of files or other circumstance, so "it worked before" is very optimistic in the SBS case :-/ The scanner should be improved ? not like it is now each version have a different set of problems.
I would not be surprised if I get problems in in the future with my files that "just works" for the moment.

It's typical to software with to little testing they routinely breaks things that have "worked before" because the do not test properly .
To many bugs comes back from the dead after they have been fixed, they can not find resources to test but they can fix each bug 3 times over the years ?