[btmoore]

Or rather something that looks very similar to the unwatchable bug.

I am beginning to think the unwatchable bug is a problem where shows in the Playlist have an invalid file pointer or handle. I think what might be going on is when you select from the PlayList and the program is unwatchable what is happening is the media codec player is being passed an invalid or null pointer or Handel, when the player tries to open the file it just spins because there is no data to play. This is why you can use the trick plays and they just increment and nothing happens, and since there is never an EOF the player has no reason to stop. So why do I think this ... you can try this little experiment for yourself that takes advantage of another code defect in the HR20.

• Go to the PlayList
• Pick a recording that you do not mind deleting.
• Play that recording
• Use what ever method you like to move to the end of that recording
• When you are prompted, delete the file
• This will bring you back to the PlayList
• You will notice that the program you just deleted is still in the PlayList
• Select the program you just deleted and play that recording again
• You should now have a black screen, if you use your ff or play you will see the time bar, it will either have a time code of 0:00 or some version of -hour:-min
• This is exactly what you see when you have an unwatchable bug

Now if you go back to the PlayList, that program will now be gone from the PlayList. This is where things differ from the normal unwatchable bug.

So why do programs in the PlayList disappear when you reboot. I am thinking upon a reboot, the HR20 validates that the items in the PlayList have valid file handles or pointers. For items that do not, the HR20 just cleans them out from the PlayList like they never existed.

It is just a theory, there would be no way to prove it with out being able to see the code and slap a debugger on it and you would need an understanding how data was being stored on the raw data partition.

How does this help us, I am not sure if it does, but it keeps me entertained trying to reverse engineer what might be going on inside until the damn thing is fixed.

 

[jkc120]

Confirmed, I can reproduce this pseudo-unwatchable bug. I've noticed this as well.

I think you're on to something. The quesion is - why is the HR20 deleting or doing something to the recording that produces a NULL or invalid pointer that causes the unwatchable bug.

One thing of note - when you delete a recording and go back into the playlist, while the item may still be listed, it IS marked as read. So why can it mark it as read but not delete it?

It would seem that, at least for this particular situation that can be recreated, the solution would be to tell the playlist thread to update the display.

Of course, that doesn't solve the problem with the unwatchable bug on normal recordings. We can only guess as to why the recordings are being deleted. But it could be as simple as a couple of threads trying to write to memory and some buffers being overflowed and corrupting the playlist.

 

[litzdog911]

Your theory seems plausible. This must be a challenging bug for the software team to fix because it's been with us since the first software releases back in September.

 

[btmoore]

Confirmed, I can reproduce this pseudo-unwatchable bug. I've noticed this as well.

I think you're on to something. The quesion is - why is the HR20 deleting or doing something to the recording that produces a NULL or invalid pointer that causes the unwatchable bug.

Totally guessing and I am grossly simplifying but imagine you created a function called start_recording() and the function did what ever magic was necessary to start spooling the stream and it returns a pointer or a handle to the start of the data for a recording. Lets say something in that magic goes wrong, and for some reason you return a null or invalid reference, but your calling process had no way of validating because you made the assumption that this function always returns the reference to the recorded stream. You store that reference in the PlayList data structure for the instance of that show. When you then go to select that show for playing, the invalid reference is used to try to open the stream and boom, unwatchable.

One thing of note - when you delete a recording and go back into the playlist, while the item may still be listed, it IS marked as read. So why can it mark it as read but not delete it?

This is likely because they are updating the read/viewed state on when you try to open the recording, they need to get the returned state of the item when it returns to the play list, you can see this is where how ever they are doing IPC it is failing. Upon returning to PlayList functions it appear they try to use asynchronous processes, and they depend on timing vs using some kind of semaphores to communicate state change before displaying the PlayList. I have not quite got the timing right to replicate it, but there are times when the PlayList item does get deleted upon exiting. This points to the some possible poor programming techniques where the programmers are depending on the luck of timing and sequence of events vs confirming state changes via return codes or IPC methods.

It would seem that, at least for this particular situation that can be recreated, the solution would be to tell the playlist thread to update the display.

Of course, that doesn't solve the problem with the unwatchable bug on normal recordings. We can only guess as to why the recordings are being deleted. But it could be as simple as a couple of threads trying to write to memory and some buffers being overflowed and corrupting the playlist.

I am guessing it may be even less complex. I wonder if the they are not exception handling correctly, some of this sure looks like to weak exception handling and poor IPC processes. Are they making sure they get a valid reference before creating the PlayList instance and/or a big null pointer is getting left in or stuffed in the PlayList data structure because of some of the goofy asynchronous or timing dependent coding techniques being used.

But all of this is wild ass guesses at what might be going on.

 

[dervari]

FYI - I found that the Keep or Delete at the end of a file DOES work if you toggle from Delete (default) to Keep and back to Delete before hitting SELECT.

 

[Milominderbinder2]

bt, good work!

I finally saw the unwatchable bug!

Everyone else had gotten theirs but I had never seen the unwatchable bug.

Your keystrokes did it for me!

I went to the end, chose delete and went back in. You are right! Even though I had just deleted it, it was still there. I tried to play it and got the -59 seconds!

So we just need to avoid the features that don't work right:
Search
Autorecord
Parental Controls (In My Playlist)
HDMI
Native Mode
Padding
Delete

It was so easy!

Maybe we have been looking at this all wrong. Maybe the Unwatchable Bug was actually the Unwatchable Easter Egg? Just something fun they left for us to find?

Seriously, we need is a page called: HR20 Known Defects and Workarounds.

- Craig

 

[btmoore]

The UI defect where deleted shows are not immediately removed still exist in 0xf6. I just tested the script and you can still simulate a unwatchable bug via the method I outlined above.

That being said, I do not know if they have fixed the actual unwatchable bug in 0xf6, only time will tell.

Regardless the bug that allows you to open a deleted program still exists, which is a minor issue.

 

[iacas]

I use Entourage for email and its database works similarly. So do most file systems, from what I know - they have a catalog that simply points to the appropriate location on the disk.

My email application - and some "catalog rebuilders" for hard drives - include functionality to "rebuild" the index based on the hard drive. The index is just about what you'd expect, and in mockup database terms, simply something like this:

Email ID LENGTH
1 43231
2 8777773
3 73232

(And so on.) If for some reason the length of an email gets off-kilter, email can show up all garbled and odd. So "rebuilding" visits the actual email portion of the database and rebuilds the index.

If the theory espoused in this thread is correct, and that missing recordings or non-playback is simply a matter of bad file pointers, it seems that the HR20 software could benefit from the option to "rebuild the index" based on what's physically on the hard disk.

Of course, like my email program or regular hard disks, these file pointers should be awfully difficult to corrupt to begin with, but any "repair" or "rebuild" tool would at least help those who had somehow mucked up their DB.

 

[Andrew_J_M]

So why do recordings disappear immediately from my My Playlist? I've never seen them in there after I've deleted them. Only twice had an Unwatchable and that was a long time ago. I'm on 0xEF.

I like the idea that magic is involved - maybe my HR20 has a larger supply of fairy dust, is that hardware or software?

 

[btmoore]

So why do recordings disappear immediately from my My Playlist? I've never seen them in there after I've deleted them. Only twice had an Unwatchable and that was a long time ago. I'm on 0xEF.

I like the idea that magic is involved - maybe my HR20 has a larger supply of fairy dust, is that hardware or software?

If you HR20 acts like mine and apparently others who have replicated my experiment, at the end of watching a show and you select delete, it returns you to the PlayList, the vast majority of times that program I just deleted still shows on the playlist even though it was deleted. If you exit the playlist and return, it will then be removed from the playlist. If your system behaves differently that is an interesting data point. Since I discovered this trick, I have seen one time when I deleted a program and returned to the playlist was it properly removed from that list.

Magic is a sophisticated advanced computer science concept. It is all the other important stuff real world hard and mundane stuff that happens that you want to ignore and dismiss and would rather not think about when talking about a theoretical problem. :grin:

 

[Andrew_J_M]

Do you mean that you watch or FF all the way to the end of the show then delete it from the pop-up option? If so I very rarely do that - normally I hit Stop and then delete it.

I'll try the other way to see what happens tonight.

 

[btmoore]

Do you mean that you watch or FF all the way to the end of the show then delete it from the pop-up option? If so I very rarely do that - normally I hit Stop and then delete it.

I'll try the other way to see what happens tonight.

Yes, that is exactly what I mean.

 

[Andrew_J_M]

Yes, that is exactly what I mean.

I just played a show to the end, selected delete from the pop-up option. It then took me back to the My Playlist screen and the show had gone. This is with 0xEF.

So my HR20 seems to be behaving differently from yours. I have 11 recordings with 77% available.

 

[btmoore]

I just played a show to the end, selected delete from the pop-up option. It then took me back to the My Playlist screen and the show had gone. This is with 0xEF.

So my HR20 seems to be behaving differently from yours. I have 11 recordings with 77% available.

I have noticed that some times, it does correctly delete, at least for me it is more the norm that it leaves it on the PlayList.

You might try a deleting a few to see what happens. It would be interesting to see what you find.

For reference, I have about 35 passes and I have ~20% free at this time

 

[Andrew_J_M]

I'll make some recordings tonight and watch/delete them. I'll let you know the results.

 

[mtnagel]

I deleted Sports Center and it was still listed in My Playlist, but once I moved down in my list and came back up it was gone.

 

[jeffster]

This is still in 10B on my machines.

 

[btmoore]

This is still in 10B on my machines.

Yep, it still is.