Stiletto 100 Memory use

[jstaebell]

When my Stiletto 100 was new, a year and a half ago, when I recorded 1 hour of a show, it used about 1% of the available memory. 100 hours of storage capacity, woot!

Now, it uses about 13% of memory for one hour - more like 6 hours of storage capacity. Not so hot. And, it seems to be accelerating, meaning I'm getting less and less capacity out of it.

I tried the device recovery, but that didn't help. I fear that the flash memory is dying, and my only option is yet another expensive forklift upgrade (I'm a former S50 user...). Anyone have any other ideas to get it back to more reasonable memory use?

Thanks, Jon

 

[My name is Matt]

What type of device recovery did you do. Some people assume that just using the update through My Sirius Studio is a recovery, but it is really what we refer to as a three finger reset. What steps did you take to perform a device recovery?

 

[ClubSteeler]

How full is your total memory?

I've always wondered how they handle memory fragmentation.

For example, you record 5 programs, A B C D E, and you erase C. Now you record F, which is longer than C. Does it physically place part of F in the C slot, and the rest after E, or put all of it after E and use C later for something shorter, or is C gone forever never to be used again? So the more fragments you have, the less usable memory space.

I don't know the answer. Considering the weakness of the software in these devices, I wouldn't be a bit surprised if they did something absolutely lazy and inefficient in terms of memory usage.

Loved songs has to cause another memory issue. If you record and erase loved songs, the recorder doesn't know how long the song you are currently recording is, so it might never ever go back and use the blank space from a previosly deleted loved song.

I don't know.

You probably need to a do true device recovery, including new firmware download. If that doesn't fix it... you're screwed.

Another word of advice.. when you erase long recorded blocks, do a complete shutdown. I have a theory that these devices don't free up memory from deleted recordings until the device is shut down. I do a shutdown at lease once a week. If I don't, I get failed recordings, and last time it happened, I had recorded and erased approximately 100 hours of content before the failure. Coincidence?

 

[My name is Matt]

For example, you record 5 programs, A B C D E, and you erase C. Now you record F, which is longer than C. Does it physically place part of F in the C slot, and the rest after E, or put all of it after E and use C later for something shorter, or is C gone forever never to be used again? So the more fragments you have, the less usable memory space.

Another word of advice.. when you erase long recorded blocks, do a complete shutdown.

Probably one of the best ways I've seen it explained. Problem is I don't know the answer. I agree with a complete shutdown and reboot after deleting a long recording. Great advice!

 

[jstaebell]

I installed the "Device Recovery" Software found here:
SIRIUS Satellite Radio - Stiletto Device Recovery

I ran the software and memory usage was 0%, all my presets & loved songs wiped out, etc. Checked in My Sirius Studio for a software upgrade, it said I had the latest. Then I recorded 3 hours of Howard; memory usage is 38%. Ouch.

Thanks for any thoughts.

 

[Allanon]

My hunch is that it's even simpler than that (on the SL2):

Allocation is linear (*), as long as you don't "shutdown" the unit. e.g. F gets allocated past E, instead of trying to fit within C. Bug: The SL2 code does not check for "out of memory" conditions, so when it gets beyond available memory, the code corrupts memory. Most SL2 users that record songs and programs have experienced this.

When you shutdown the unit, on the next boot it does some cleanup. I guess that it gets rid of framgmentation (or ignores small fragments). Once in a while, when doing the cleanup, it notices that fragmentation has reached a certain threshold that would require long enough processing and it displays "Updating Library".


I can't say that this is really it, but it would explain the observed behavior of the SL2 (and the problems that people complain about). People that record many long programs and don't regularly shutdown their unit get memory corruption (e.g. problems playing back programs) within 2 to 3 weeks. I do record long programs, and yet, I have been able to avoid getting corruption for long periods of time by shutting down the unit daily. Unfortunately, I often modify the programming and sometimes I screw up by modifying a program while it is being recorded. The weak memory management of the SL2 leads to memory corruption in such case (instead of disallowing the modification or handling the concurrent modification correctly).


(*) When you think about it, the SL2 never knows in advance how much space it will need for recording (the stream has variable bit rate), so it has to allocate linerarly, unless you put in place a relatively complex memory management scheme, which would be way too costly in terms of performance (and heat). So, I'm pretty sure the SL2 programmers took the easy approach. Actually, there are so many dumb bugs (no checking of "out of memory", and many other conditions) that I don't think they could even imagine the more complex memory management scheme.

Of course, if memory was managed as a file system, it wouldn't suffer from fragmentation, but I don't think SL2 programmers wanted to design a file system, nor that their bosses wanted to pay for a file system license.

How full is your total memory?
For example, you record 5 programs, A B C D E, and you erase C. Now you record F, which is longer than C. Does it physically place part of F in the C slot, and the rest after E, or put all of it after E and use C later for something shorter, or is C gone forever never to be used again? So the more fragments you have, the less usable memory space.

 

[IdRatherBeSkiing]

My hunch is that it's even simpler than that (on the SL2):

Allocation is linear (*), as long as you don't "shutdown" the unit. e.g. F gets allocated past E, instead of trying to fit within C. Bug: The SL2 code does not check for "out of memory" conditions, so when it gets beyond available memory, the code corrupts memory. Most SL2 users that record songs and programs have experienced this.

When you shutdown the unit, on the next boot it does some cleanup. I guess that it gets rid of framgmentation (or ignores small fragments). Once in a while, when doing the cleanup, it notices that fragmentation has reached a certain threshold that would require long enough processing and it displays "Updating Library".


I can't say that this is really it, but it would explain the observed behavior of the SL2 (and the problems that people complain about). People that record many long programs and don't regularly shutdown their unit get memory corruption (e.g. problems playing back programs) within 2 to 3 weeks. I do record long programs, and yet, I have been able to avoid getting corruption for long periods of time by shutting down the unit daily. Unfortunately, I often modify the programming and sometimes I screw up by modifying a program while it is being recorded. The weak memory management of the SL2 leads to memory corruption in such case (instead of disallowing the modification or handling the concurrent modification correctly).


(*) When you think about it, the SL2 never knows in advance how much space it will need for recording (the stream has variable bit rate), so it has to allocate linerarly, unless you put in place a relatively complex memory management scheme, which would be way too costly in terms of performance (and heat). So, I'm pretty sure the SL2 programmers took the easy approach. Actually, there are so many dumb bugs (no checking of "out of memory", and many other conditions) that I don't think they could even imagine the more complex memory management scheme.

Of course, if memory was managed as a file system, it wouldn't suffer from fragmentation, but I don't think SL2 programmers wanted to design a file system, nor that their bosses wanted to pay for a file system license.

I think the "Updating Library" happens when it encounters an error. Its kind of like when you power off a PC and it runs the disk fixer upon reboot. In my opinion, the SL2 would probably be a lot more stable if they ran this upon every restart (since they obviously have developed an unnatural attachment to this bug and seem to want to keep it in the software).

 

[My name is Matt]

Great explanation Allanon. The more I dig into this the more it sounds like a shut down, not sleep, will solve a lot of problems.

 

[jstaebell]

Any suggestions for this SL-100? Memory use is now up to 25% for one hour of recording, for a total capacity of 4 hours. Ick. Do I have any choice other than buying an SL2?

 

[TOM C.]

are you sure its a s-100 and not a s-10, :idunno: