If Sirius is serious about fixing some of the worst SL2 bugs, here are some reproducible ones:
1- Schedule a recording at 10:00am (pick whatever time you want). Leave your SL2 on the dock, but not playing anything. At 10:03am, tune your radio to listen to the ongoing recording. Bug: After a little while (1 to 10 minutes), the SL2 will stop playing and go back to the main menu. Workaround (until the bug is fixed): rewind a few seconds -> the SL2 does not stop playing when it is playing a few seconds back. Go figure why...
2- Schedule a recording at 10:00am (pick whatever time you want). At 10:03am, go to the Library. Go and select the ongoing recording, then delete it. -> You will atomatically get memory corruption from now on, until you do a Device Recovery (using your PC).
3- Schedule a regular long recording (something like 6 hours long) repeating
Daily. Leave your SL2 on the dock (or take it a few times on the go and put it back on the dock for the recording to happen). After a while (two to six weeks), memory corruption will happen, unless you do a FULL
shutdown of the SL2 regularly, before the memory corruption bug hits. If you record more, let say, 15-20 hours/day, you should hit the bug within less than 2 weeks.
4- Schedule a "regular" recording at 10:00am (pick whatever time you want). At 10:03am go to the Recording menu and change the parameters of the ongoing recording. You're then almost guaranteed to cause memory corruption.
5- In general, when a recording is ongoing, it's very easy to cause the SL2 to get into memory corruption. It seems that the SL2 programmers forgot about "concurrency" bugs. The SL2 should either:
- deny an operation (and tell the user why), if it would otherwise cause trouble due to a concurrent activity, or
- do the requested operation, but make sure things are done properly and no memory corruption is caused.
Hoping this helps Sirius programmers reproduce some of the most notorious problems.