Forum Discussion
Baradanikto
9 years agoRoku Guru
I have resolved this problem. And, here's what I learned.
I, like others before me, made the assumption that the Sample Video Player template is bug free. It is not. After digging deeper into the code, I discovered that my problem with the Resume button always showing up was caused by the code. The Sample Video Player code displays the Resume button regardless of the state of the video. In the function, refreshShowDetail(), it adds the button to the screen unconditionally. To resolve this, I had to add a check for the playback position of the last video. My code morphed into:
I also decided to specify a section, rather than using the default, when reading and writing the playback position to the registry. I called it “PlaybackPostion” and this allowed me to track the reading and writing of this value.
I found that a major stumbling block in debugging this code is the use of print statements as a debugging tool. The existing print statements displayed in the debug console as a mass of strings. This made it difficult to determine where I was in the code at specific times. I reconstructed the print statements to follow this scheme: “source code file name::function name”
I placed a print statement at the beginning of each function I was interested in. For example,
I then used “tab” on the print statement for all other print commands that originated from within the function. For example,
This allowed me to see more quickly and easily where I was in the code since the function execution was delineated by tabs.
Long story short, if you are reading this because you have the same problem, do not assume that the sample code is “clean”. If it doesn't do what you expect, debug the code and assume nothing.
I, like others before me, made the assumption that the Sample Video Player template is bug free. It is not. After digging deeper into the code, I discovered that my problem with the Resume button always showing up was caused by the code. The Sample Video Player code displays the Resume button regardless of the state of the video. In the function, refreshShowDetail(), it adds the button to the screen unconditionally. To resolve this, I had to add a check for the playback position of the last video. My code morphed into:
if PlayStart <> "0" and PlayStart <> invalid then
screen.AddButton(1, "resume playing")
endif
screen.AddButton(2, "play from beginning")
screen.SetContent(show)
screen.Show()
I also decided to specify a section, rather than using the default, when reading and writing the playback position to the registry. I called it “PlaybackPostion” and this allowed me to track the reading and writing of this value.
I found that a major stumbling block in debugging this code is the use of print statements as a debugging tool. The existing print statements displayed in the debug console as a mass of strings. This made it difficult to determine where I was in the code at specific times. I reconstructed the print statements to follow this scheme: “source code file name::function name”
I placed a print statement at the beginning of each function I was interested in. For example,
print "appDetailScreen::refreshShowDetail"
I then used “tab” on the print statement for all other print commands that originated from within the function. For example,
print tab(5)">> refreshShowDetail: 'PlayStart' = "; PlayStart
This allowed me to see more quickly and easily where I was in the code since the function execution was delineated by tabs.
Long story short, if you are reading this because you have the same problem, do not assume that the sample code is “clean”. If it doesn't do what you expect, debug the code and assume nothing.