Open GoogleCodeExporter opened 8 years ago
I was about to say I can't reproduce this, but I seem to recall *very* rarely
seeing
this on my system. I can't reproduce it now, of course.
However, for me EyeTV is nearly always running. I suspect this might happen if
eyetv
is not running for some reason, but PyeTV somehow still has the list of
recordings
(which means that EyeTV had to have been running at some point.) Maybe EyeTV
quit
while Front Row was running, after responding to the request for the recording
list.
BTW, I've made an update to SVN, which won't help this issue, but it doesn't
hurt to
be up to date.
About the only thing I can suggest is to tweak etv.py's PlayRecording function.
Adding something like:
app("EyeTV").activate()
time.sleep(1)
might help. If it does, I suggest backing off on the time.sleep to 0.25 sec and
seeing if it still works, and or eliminating the sleep entirely.
Another setting which has occasionally caused troubles is in
EyeTV->Preferences->General
I keep "Always open tv in a new window" toggled off.
Original comment by jon.chri...@gmail.com
on 1 Jul 2009 at 6:27
I can confirm that I see this behavior quite frequently as well.
EyeTV is always running when it occurs, but it has not
"recently" been activated (and is almost certainly not the
frontmost app prior to launching FrontRow).
Always-in-a-new-window is off.
I'll try the PlayRecording tweak next week and see whether it helps improve the
initial success ratio.
Original comment by charl...@pobox.com
on 6 Jul 2009 at 2:40
Weird. I never saw this problem, then I read this issue, *tried* to hit it and
I did 4 times in a row by quitting
EyeTV, starting FrontRow, and trying to watch a recording. Wish I never read
the issue now! :-) After repeating
the process with EyeTV running before I entered FrontRow, it worked fine and
every time after that. Now I can't
reproduce it even if EyeTV isn't running first. I wonder if it has something
to do with the disk holding the
recordings being spun down.
Original comment by robertah...@gmail.com
on 20 Aug 2009 at 10:47
I think there are two things going on here:
1) It's important to realize that Front Row can be "running" but not visible.
After
a reboot, Front Row is not running at all, until activated. After activated,
though,
is stays running (at least for a while) even when hidden.
So, if Front Row is not *running* and EyeTV is not running when you start Front
Row,
then the call to ETVMenuController.StartEyeTV will call EyeTV.GetRecordings().
This
function calls app("EyeTV").recordings.get() in a loop up to 10 times to make
sure
EyeTV has time to start. (NOTE, it's arguably an EyeTV bug that we have to call
this
in a loop, because if EyeTV is just starting, it's possible for
app("EyeTV").recordings.get() to return an empty list, instead of just waiting
for
the correct answer. It's not an appscript thing, it'll happen in applescript as
well.) app("EyeTV").recordings.get(timeout=60) should wait a full minute
before it
returns, but it will return with an empty list after a few seconds. Apparently
EyeTV
will respond with an empty list during startup if it has not yet read its
database of
recordings, sigh...)
In any case, unless EyeTV has returned a valid recording list, there will be
nothing
in PyeTV's list, and nothing on which to press "Play".
The upshot of all of this is that starting Front Row (and entering the PyeTV
section)
starts EyeTV.
However, if Front Row is just *hidden* and EyeTV is not running but we've
already got
the recording list, this means that EyeTV was once running but has been quit.
So it *is* possible to get into a state where PyeTV has the recordings list, but
EyeTV is not running.
2) I suspect that, if EyeTV is not running there may not be enough time
(depending on
the disk spindown state, CPU speed, amount of memory, other processes running,
etc)
to launch EyeTV and start the recording before the appscript commands timeout.
If these commands timeout, it's possible that a python exception of some sort
will be
thrown and there is no try/catch surrounding the PlayRecording's commands, so
that
could cause Front Row to exit, which would explain the observed symptoms in the
original bug report.
It *should* be possible to add a timeout=whatever keyword argument to all the
play
calls in etv.py's PlayRecording function, but I'm not convinced appscript is
actually
respecting the timeout value, and see above about EyeTV and timeouts.
In any case, it might be worth trying:
app("EyeTV").play(rec.rec,timeout=30)
in PlayRecording and adding try/catch protection.
With the current version, though, if you go hit this bug is there some sort of
entry
in the log (Applications->Utilities->Console: Console messages)
Original comment by jon.chri...@gmail.com
on 21 Aug 2009 at 5:58
My observation - which I haven't been able to quantify - is that if I first
watch a video source through one of the
iTunes-linked aspects in Front Row and then select a video via PyeTV, I will
typically experience this behavior.
Namely that the selected program never plays and the background Front Row
process quits (after spinning the
WaitController "launching EyeTV" text ) without leaving a crash log behind.
Adding:
app("EyeTV").activate()
time.sleep(1)
to the PlayRecording method has had no effect.
Original comment by charl...@pobox.com
on 21 Aug 2009 at 6:17
By "the Front Row process quits," I should make it clear that I mean that the
Front Row process itself exits
around the time PyeTV tells it to hide itself. The process disappears from the
process list and the next launch of
Front Row takes longer because it cannot simply wake the hidden Front Row
process.
(Again, this is conditional on whether an iTunes-backed video has been played
during the same invocation of
that Front Row process.)
Original comment by charl...@pobox.com
on 21 Aug 2009 at 6:34
My wife reports this too. What she sees is that
1) if the computer has been idle for a while, navigating to and playing a
recording
causes the desktop to appear (FR is hidden) but the recording does not play.
2) Immediately going back into Front Row, and re-trying to play the same
recording
works, apparently every time.
Original comment by jon.chri...@gmail.com
on 28 Nov 2009 at 9:42
Can anyone confirm seeing this with PyeTV-2.0?
Original comment by jon.chri...@gmail.com
on 2 Dec 2009 at 11:02
I've seen something similar with trying to watch live tv. I choose a channel
in the channel list and FR hides but
no EyeTV window is opened. I haven't taken the time to troubleshoot it further.
EyeTV 3.2.1, SL 10.6.2, PyeTV 2.0
Original comment by jaso...@mac.com
on 3 Dec 2009 at 12:58
I can confirm still seeing this with PyeTV 2.0. The behavior is the same. The
Front Row Process quits (instead of
remaining in the background) before the PyeTV thread can send the requisite
apple Events to EyeTV.
10.5.8 Core Duo Mini with 1GB RAM, PyeTV 2.0, EyeTV 3.2.1.
My guess is that this has to do with resources in Front Row. If it determines
(my suspicion is because of its own
usage) that it would be too costly for the Front Row process to remain in the
background, then it exits gracefully
as soon as PyeTV tells EyeTV to launch. In short, the auto-exit feature - or
its equivalent - kicks as soon as Front
Row would otherwise be in the background.
Original comment by charl...@pobox.com
on 6 Dec 2009 at 5:01
I too have had this problem both in 1.3 and 2.0. It appears limited to the
Channel
Menu. I can select the "Guide" and "My Recording" and those work fine.
However, if
I attempt to open a specific channel, I see the desktop and then a short time
later,
it brings back Front Row.
Original comment by David.Bi...@gmail.com
on 8 Dec 2009 at 3:49
I have this issue happening 100% times with both leopard and snow leopard with
new PyeTV versions (with
Leopard and 1.2 I did not have this problem). Any of recordings can not be
wathed through pyetv. All
channels and Program guide are working ok. EyeTV is running "background" before
going to frontrow.
1. Go to a recorded show in FrontRow
2. Select Play (or restart)
3. Spinning Wheel, Frontrow closes, desktop appears and stays for a while
(EyeTV does not open)
4. Returns to Front row menu -> 2. "Play (or restart)" and it is not helping if
I try to "play" again but 3. and 4.
repeats.
It is not helping if I have eyetv as active program before going to front row
or not.
Environment 1. iMac, OS X 10.5.8, EyeTv 3.2.1, PyeTV 2.0
Environment 2. Mac Mini, OS X 10.6.2, EyeTv 3.2.1, PyeTV 2.0.1
Original comment by teemu.ko...@kolumbus.fi
on 9 Dec 2009 at 1:46
I believe I've just checked in the fix for this. It seems to have worked for
me.
However, for me the issue is *very* intermittent---I have to leave FR running
for
hours (e.g. overnight) and then the first attempt to play a recording will
fail. If
I re-start FR and try to play the same recording it always works. That seems
to be
consistent with what some users were seeing, but others seemed to have failure
all
the time.
In any case, I've totally re-vamped the way recordings/channels are launched
from FR.
Can anyone checkout the changes and confirm this works for them?
Original comment by jon.chri...@gmail.com
on 10 Dec 2009 at 6:57
It fixed my channel selection problem. Thanks.
Original comment by jaso...@mac.com
on 11 Dec 2009 at 1:25
It looks like the problem is back with EyeTV 3.3. When the problem occurs, I
noticed that there is either no guide
info in the Channel list or the same guide info is repeated for every channel.
I also noticed that if I manually go into EyeTV and view a channel, accessing a
channel through Front Row works
again and each channel has proper guide info. It seems that only after opening
EyeTV does this problem occur.
Original comment by jaso...@mac.com
on 17 Dec 2009 at 10:28
Jason, are you using the released version, or the version from svn?
Original comment by jon.chri...@gmail.com
on 17 Dec 2009 at 10:34
Sorry, I'm on the svn version from Dec 10.
Original comment by jaso...@mac.com
on 17 Dec 2009 at 10:51
Jason, could you describe in detail what you're seeing again.
> It seems that only after opening EyeTV does this problem occur.
Isn't quite clear to me.
-Jon
Original comment by jon.chri...@gmail.com
on 17 Dec 2009 at 11:02
It happens after a fresh launch of EyeTV. If you've done other stuff in EyeTV
such as watching live TV or
watching a recording, then it doesn't happen.
Original comment by jaso...@mac.com
on 17 Dec 2009 at 11:33
Jason, I see you're using SVN and other tools; do you know python?
What happens if you forget PyeTV and just try etv.py?
something like
import etv
channels=ETV.GetChannels()
for chan in channels:
print chan.GetProgramInfo()
(I'm not on my mac, so I can't test that, but it's close...)
First, what happens when you run that script:
1) with a fresh launch of EyeTV
2) after you've opened a liveTV window or recording?
Second, can you confirm that the missing guide info exists if you:
1) Restart EyeTV (so you have a fresh launch)
2) kill Front Row
3) Restart Front Row and navigate to PyeTV's channels list. Do you see correct
guide
info here?
3.1) Hide (not kill) Front Row and then manually open a Live TV
window/recording in
EyeTV.
Go back into Front Row and check the channel list again. What do you see?
Thanks,
Jon
Original comment by jon.chri...@gmail.com
on 18 Dec 2009 at 12:23
I don't know python but I am technically minded and can figure things out
somewhat.
I tried running etv.py and got the following:
bash-3.2# python etv.py
Traceback (most recent call last):
File "etv.py", line 4, in <module>
from appscript import *
ImportError: No module named appscript
I tried creating a python script with what you included above and got the
following:
bash-3.2# python test.py
Traceback (most recent call last):
File "test.py", line 1, in <module>
import etv
File "/System/Library/CoreServices/Front
Row.app/Contents/PlugIns/PyeTV.frappliance/Contents/Resources/etv.py", line 4,
in <module>
from appscript import *
ImportError: No module named appscript
For the second test, no change in guide data for step 3. For step 3.1, the
guide data was there.
Original comment by jaso...@mac.com
on 18 Dec 2009 at 2:13
I'm using the new EyeTV 3.3 with PyeTv 2.0.1 on Snow Leopard (10.6.2) and I'm
having
the same quirks that Teemu Kontio.
The recordings aren't working at all. It drops Front Row, reveals the desktop,
nothing happens, gets back to Front Row. Clicking again on the same doesn't do
anything. No changes if EyeTV is on the background, running, used before/not
used before.
Channels work mostly, but sometimes EyeTV stays in the background open when
taken
back to Front Row.
Original comment by niko.an...@gmail.com
on 18 Dec 2009 at 10:39
I did found out that all recordings that will not play through pyeTV are having
scandinavian letters either in
Title, Episode or description fields (ä,ö or å is found almost from 100% of
my recordings). If I remove those
letters from fields then recordings are shown. Is there any quick solution to
fix this? I would not like to
remove all scandinavian letters from my recordings ;).
Thank you,
-Teemu
Original comment by teemu.ko...@kolumbus.fi
on 3 Jan 2010 at 7:17
Could this be the same bug as issue 47?
http://code.google.com/p/pyetv/issues/detail?id=47
Original comment by thomas.h...@gmail.com
on 10 Jan 2010 at 4:34
That's it! The new 2.5.1 version of PyeTV for Snow Leopard fixed all my
problems with EyeTV 3.3 and 10.6.2.
Many thanks, glad to have PyeTV back! :)
Original comment by niko.an...@gmail.com
on 13 Jan 2010 at 6:32
2.5.1 does not fix the problem I'm having.
Original comment by jaso...@mac.com
on 14 Jan 2010 at 5:00
I've noticed that, if EyeTV is not loaded, when I launch pyeTV, loading eyeTV
could take a while.
But everything works fine with EyeTV 3.3 on 10.6.2.
Best regards,
Original comment by Vilo.Rei
on 14 Jan 2010 at 6:35
Original issue reported on code.google.com by
juergen....@gmail.com
on 29 Jun 2009 at 8:28