Closed GoogleCodeExporter closed 8 years ago
Forgot to mention Eyetv is 3.2.1
Original comment by heltb...@gmail.com
on 30 Nov 2009 at 8:34
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
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
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
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
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
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
Not a PyeTV bug.
Original comment by jon.chri...@gmail.com
on 2 Dec 2009 at 11:02
Original issue reported on code.google.com by
heltb...@gmail.com
on 30 Nov 2009 at 8:28