A-C is good - D-Z not so

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Play any recording that starts with letter "D" or later. Briefly shows 
desktop, then returns to Front Row.

What version of the product are you using? On what operating system?
2.0 on Snow Leopard. Remember a similar problem using 1.3 on Leopard. Then 
reverted to 1.2 which solved the problem. No such option this time :-( 

My kids really want to see more than "B"ob the Builder and "B"arbapapa, 
for example "P"ostman Pat and "S"haun the Sheep are no show at the 
moment :-(. (and the kids are lost trying to use EyeTV interface - Elgato 
really ought to throw a lot of dough after your project...)

Please provide any additional information below.
Tried to remove all recordings starting with "C" and the first recording 
starting with "D" thinking one of them might have messed with the index 
somehow but to no avail :-(

Original issue reported on code.google.com by heltb...@gmail.com on 30 Nov 2009 at 8:28

[GoogleCodeExporter]

Forgot to mention Eyetv is 3.2.1

Original comment by heltb...@gmail.com on 30 Nov 2009 at 8:34

[GoogleCodeExporter]

This is really odd.  I can't quite see how it'd be a problem with PyeTV itself 
though.
Have you tried rebooting, which would reset Front Row and EyeTV?  PyeTV doesn't
really keep an index of recordings, beyond what EyeTV tells it.

Can you tell if there's anything interesting in the console log
(/Applications/Utilities/Console) from the time where EyeTV fails to launch?

Essentially all PyeTV does to play a recording is send applescript (an Apple 
Event,
technically) to EyeTV to tell it to play a recording with a specific ID.  The
specific ID is the one given to PyeTV as part of the return from another Apple 
Event.

If you can paste applescript into the Apple Script editor, I can send you some
applescript to simulate what EyeTV does and you can see if it works w/o PyeTV 
in the mix.

Another option is to try downgrading to a different version of EyeTV and see if 
that
helps.

-Jon

Original comment by jon.chri...@gmail.com on 30 Nov 2009 at 9:03

[GoogleCodeExporter]

Hi Jon Thanks or your friendly advice, really appreciate your work - and my 
kids do 
as well :-)

The log says something like this App: startup failed with tickcount 1 - through 
 20 
after this squence it returns to Front Row. A successful playback has none of 
these.

I probably should mention that I have a lot of recordings (like 180 or so)

I'll be happy to try to paste some Applescript into the Apple script editor and 
see 
what happens

Original comment by heltb...@gmail.com on 30 Nov 2009 at 9:17

[GoogleCodeExporter]

I'm working from memory here, since I don't have access to my mac right now, 
but a
tweak to PyeTVWaitController.py might fix this.

The path to that file should be something like:

/System/Library/CoreServices/Front
Row.app/Contents/Plugins/PyeTV.frappliance/Contents/Resources/PyeTVWaitControlle
r.py

Around line 52 in that file is a line

   wait_before_exit_ticks=20

If you change that 20 to a higher number (say 40) and try again it might work.  
It
could just be a timing issue for your particular combination of HW and # of
recordings.  In case you're not familiar with Python, white space is 
significant, so
be careful editing the file to not change the spacing.

You might need to restart Front Row before the changes will take effect:
The following commands in terminal should do it.

        kill `ps -aex | grep "Front Row" | awk '{print $$1}'`
        killall ScreenSaverEngine
        killall ScreenSaverEngine

Luck!
-Jon

Original comment by jon.chri...@gmail.com on 30 Nov 2009 at 9:26

[GoogleCodeExporter]

Hi Jon

No sorry it didn't do the trick, it just takes longer time until it returns to 
Front 
Row (tried 40)

I compared the logs for succesfull vs unsuccesfull playbacks and the first 
difference I notice is that a succesfull playback starts with 
"PyeTV: PlayRecording called to play [recording][timestamp]"
That line is never displayed on an unsuccesfull playback attempt. If it tells 
you 
something then great :-) 

Otherwise I could try to reenter the timing delays removed when going from 1.2 
to 1.3

BTW: My hardware is a 2009 mac mini, Core Duo 2Ghz, 2GB RAM 

Thanks for your time!
Martin

Original comment by heltb...@gmail.com on 30 Nov 2009 at 9:56

[GoogleCodeExporter]

again, working from memory here, you might want to try the following 
AppleScript:

tell app "EyeTV"
recordings
end tell

That should give you a list of all recording ids, in the command window.

Choose one which you think is in the D-Z set (I forget how to tell), and try

tell app "EyeTV"
play recording whatever_your_id_is
end tell

and see if it works.

Alternately, if you have appscript and are comfortable with python you can copy
etv.py (or grab it from the google code page) and try

import etv
recordings=ETV.GetRecordings()
for r in recordings:
   ETV.PlayRecording(r)

and make sure each one will play.

Original comment by jon.chri...@gmail.com on 30 Nov 2009 at 10:34

[GoogleCodeExporter]

You're absolutely right! It seems my EyeTV installation have been messed up 
somehow -
 - firing the apple script commands directly acts just like PyeTV ie. some 
recordings play fine while some do not (actually most do not). What originally 
led 
me to believe the problem was with pyeTV was the fact that I had a similar 
problem 
when I upgraded to 1.3 which was solved by downgrading to 1.2 of pyeTV. I 
should 
probably try a reinstall of eyeTV. Thank you very much for your helpful advice!

Best regards
Martin

Original comment by heltb...@gmail.com on 1 Dec 2009 at 9:31

[GoogleCodeExporter]

Not a PyeTV bug.

Original comment by jon.chri...@gmail.com on 2 Dec 2009 at 11:02

• Changed state: Invalid