SDS100 crashing like 436/536HP?

im just wondering, has anyone noticed the SDS100 crashing like the 436/536HP does all the time.

my 436/536HP's all crash weekly, and more so if they get hung up on Digital carriers conventionally in discovery mode or digital Trunked systems in discovery mode, i also suspect if the discovery mode session reaches a certain point of accumulation of either entries in the detail file or audio files it will crash.

I generally don't record audio to the SD card, and if I do, I don't let more than a day or two's worth of transmissions accumulate before moving them off the card.

And I've not had a crash with my 436 or 536 in years, or ever with my SDS100 (which I got when it was first released). If you want to record audio, ProScan is a better option--it records directly to your computer instead of periodically having to shut down the scanner to move audio files. And if you record from the 536 WiFi stream, the audio quality is significantly better--fewer digital/analog conversions between transmitter and playback.

radioman2008 said:

im just wondering, has anyone noticed the SDS100 crashing like the 436/536HP does all the time.

my 436/536HP's all crash weekly, and more so if they get hung up on Digital carriers conventionally in discovery mode or digital Trunked systems in discovery mode, i also suspect if the discovery mode session reaches a certain point of accumulation of either entries in the detail file or audio files it will crash.

Click to expand...

Yes, the loaner SDS100 I have has exhibited the crashing - as with the x36 models, when recording and the card starts filling up. However, on the plus side, it seems to take alot longer before the crashing begins and, unlike the x36 models, the recording remains enabled after the crash/reboot.

On a related note - mostly good - sluggish responses to button presses (usually during digital decoding and/or when the SD card starts filling up) on the SDS100 is better but not solved.

radioman2008 said:

im just wondering, has anyone noticed the SDS100 crashing like the 436/536HP does all the time.

my 436/536HP's all crash weekly, and more so if they get hung up on Digital carriers conventionally in discovery mode or digital Trunked systems in discovery mode, i also suspect if the discovery mode session reaches a certain point of accumulation of either entries in the detail file or audio files it will crash.

Click to expand...

It's true that the X36HP's have issues when the microsd card reaches 2GB of data.The crashing of the SDS100 is most likely unstable firmware or a corrupted micro SD card. You're better off picking up a new microsd card with at least 32GB of storage.

FWIW - I've tried many different cards on the x36 - even the one recommended (much later) by Uniden - same result.

troymail said:

FWIW - I've tried many different cards on the x36 - even the one recommended (much later) by Uniden - same result.

Click to expand...

Does the crashes come when approaching 2GB of data or when the card is getting close to full? If the former then the larger cards may not solve the issue. If the latter (at least on larger capacity cards) then it is likely a card-fullness type issue.



Also, is it doing so with the latest firmware versions? I haven't seen any firmware notes that discuss this but it should at least be tried...

N9JIG said:

Does the crashes come when approaching 2GB of data or when the card is getting close to full? If the former then the larger cards may not solve the issue. If the latter (at least on larger capacity cards) then it is likely a card-fullness type issue.

Click to expand...

It is around 2Gb...

On the 536, I recall long ago seeing "card full" messages for smaller cards. I suspect it did this while using that card because the card really did fill up before it hit that "problem" number (2Gb+, > 35,000 recordings, etc.).

Other (most) times, I have a much larger card in use and that's when the crashes are seen.

Also, is it doing so with the latest firmware versions? I haven't seen any firmware notes that discuss this but it should at least be tried...

Click to expand...

This has occurred on every f/w version as far as I know.

I've never seen Uniden acknowledge it was a problem much less indicate they fixed in in any version of firmware (I guess I could have missed it but I don't think so).

I typically always apply f/w releases as they are announced.

It's due to the limitations on the filesystem used on the SD card. Uniden chose to use FAT for compatibility reasons with Windows PCs, but FAT is kind of terrible. I understand Uniden's choice though. There really isn't an NTFS driver that can work on the processor in the scanner, and Windows only knows how to do FAT and NTFS, so they are stuck unless they decide to drop support for Windows.

Is there a limit to what a single folder or directory can hold?

FAT32
Maximum disk size: 2 terabytes
Maximum file size: 4 gigabytes
Maximum number of files on disk: 268,435,437
Maximum number of files in a single folder: 65,534

Click to expand...

Since the scanner dumps all its recordings into the same directory, it can get over the limit of 65k files in the same directory in a few days.

An average recording file size of 0.3Mb * 65k files = 2Gb of data.

Many FAT fikesystem drivers will corrupt other files on the same fikesystem if the system is asked to go beyond its design limitations. This leads to crashes when the scanner attempts to use the fikesystem.

I keep am extra SD card with the same favorites lists, but empty recording and discovery directories handy and swap them out when needed.

Uniden really ought to enforce slightly lower limits on the recording and discovery directories and rolling their directories to resolve this. If they get to a limit, then rename the recording directory to recording<number>, create a new recording directory and start dumping data there. They could also run a check disk on the FS every now and then to warn the user.

It wouldn't fix SD cards that are not able to keep up with that many write cycles, but at least filesystem corruption would happen slightly less often.

Yeah, the problem is FAT, not Uniden's decision to dump all recordings into a single directory. NTFS would do nothing to fix this - dumping tens of thousands of files into one location is always a recipe for disaster. I guess creating daily folders was too hard of a concept...

@slicerwizard: I agree. A smarter use of FAT would have resolved the issue.

A smarter filesystem would have also fixed it. There are filesystems that are set up for hundreds of millions of files in the same directory.

unusedusername said:

Since the scanner dumps all its recordings into the same directory, it can get over the limit of 65k files in the same directory in a few days.

Click to expand...

Not for normal recording. Subfolders are created, and files are stored 100 per subfolder.

jonwienke said:

Not for normal recording. Subfolders are created, and files are stored 100 per subfolder.

Click to expand...

Is that new? I remember playing with recording when I first got my 436/536s and saw that it dumped 1k+ files into the same directory.

It would be pretty cool if they fixed it.

Its been like that for several years...

this is interesting info, thank you for sharing. i understand the FAT structure limitations now as some of you have mentioned.

theres a few things i do to deal with this, but i still get crashes, usually 1 of my 7 436/536HP units will crash a day, so over the course of a week i might have 3-5 crash. i use a program called wondershare for file recovery and it works great most of the time. as soon as i realize a crash has occurred i pull the card and recover the lost directory, plus any other session directories that were not affected by the crash. i keep a holder with about 7 SD cards pre programmed ready to go, particularly handy on road trips. most of my cards are 16-32GB and they all have the potential to crash the same as the mentioned 2GB so the fat thing makes sense.

i keep a master image that i update and change when needed containing all my pre configured sessions.

i edit each session summary file for maximum recording by changing the 600 second reference to either 9999 or 99999, this really works well.

some sessions, i lock out the really common dispatch channels so it can take the time to hear less common talkgroups. then other sessions have some of the dispatches and i rotate sessions of scanners dedicated to the trunked system usually on a daily basis.

the discovery mode file structure saves me SOOOOOOOOOOOOOOO much time because if i record the non discovery way, it just dumps all talkgroup audio in to bulk directories which require me to transfer all those individual files to a single directory, then sort them by tag, then create sub directories for every talkgroup. discovery eliminates ALL of that. i prefer discovery for the way i am storing files but i understand that might not work for some, but i think if more people understand how it sorts all the talkgroup audio easily they might use it more with edited session summary files.

as 436HP units get cheaper, i plan to add more to my collection for 24/7 recording and if i can find a good deal on a SDS100 i will eventually pick one up

Use ProScan. You record directly to the computer, and you can create your own custom recording folder structure, organized by date, system, talkgroup, etc.

Or use MediaMonkey - with proper fav list tagging it will sort lodacross muliple sub directories and ley you view about any way needed.



Or even pull multiple scanners (as Jay911) does.

It still amazes me to see folks provide "work arounds" (some that make no sense at all for mobile operation as you'd expect using a handheld radio) to get past known deficiencies.

Anyway - some things I've learned over the past few weeks....

• when the SDS started crashing/rebooting, it had something like 70k+ recordings on it (I don't recall now - maybe 5Gb of recordings) so I'm not sure why this problem exists on the x36 at 35k/2Gb but not the SDS....
  
• before clearing the card, I checked, it was (and still is now after reformatting/re-prepping) using FAT32 -
  
• as with the x36, a new timestamped folder is created after every 100 recordings (or at startup).
  
• the recordings don't account for cases where the radio stopped on a talkgroup but no audio is processed - at least most of the time. While it makes sense not to record silence it also doesn't fully reflect what the radio was doing in real time
  
• you can put (copy back) more than 1,000 recordings in a single folder and playback on the radio but the radio appears to have a fixed limit of 1000 on replay (seems to ignore the rest).
  
• recordings made with the SDS100 still indicate internally that they were made on a BCDx36HP (vs.HP-1 or SDS100) and will play on a x36 radio but the displayed recording metadata is corrupted while playing
  
• the SDS seems to continue to try to receive (something) while in replay mode - at least the noise value field continues to display stuff (I though initially this was coming from the recording but that does not appear to be the case).
  
• I still don't understand why recording playback to this day doesn't show the recording timestamp - instead the radio continues to display the current time

As I said - just some observations.

for me, i dont have space for 7 laptops running these other programs to be connected to each scanner, if im understanding it correctly. all of these work independently, i take some of them mobile aswell on any given day depending on where i am driving to.

You can run 7 instances of ProScan on one computer. You don't need a separate computer for each scanner.

I am routinely running up to 2 dozen instances of ProScan, along with several copies of Pro96Com, ARC products etc simultaneously on one PC.