pyetv not working correctly with EyeTV 3.1.1

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Enter Front Row with Apple Remote
2. select EyeTV
3. select Program Guide

What is the expected output? What do you see instead?
Expected output is program guide.  I see a small EyeTV window that flashes with 
the "play" icon 
in the upper left corner. Program information is never displayed.

What version of the product are you using? On what operating system?
EyeTV: 3.1.1 (4907)
OSX 10.5.6
pyetv 1.2

Please provide any additional information below.
Additional issues with all playback functions in pyetv.

Original issue reported on code.google.com by mmcc...@gmail.com on 20 Mar 2009 at 3:01

[GoogleCodeExporter]

Observed behavior, when selecting a recording to play included:

* EyeTV windows not going to fullscreen when selected via Play or Restart from 
PyeTV
* EyeTV thinking window content was paused when it was playing (always displays
"play" icon in upper corner.
* "Play" button on Apple remote briefly pauses screen, but then play toggles 
back on
(if started from within Front Row).
* Closing a window that PyeTV had launched causes that window to immediately 
reopen.

Note that I had previously commented out ETV.HideWindows() calls in
PyeTVWaitController.py from 1.2 to enable the context switching back to Front 
Row to
complete successfully. I tried it both with the original HideWindows() call in 
place
and with it still removed. The same behavior was observed in both cases.

Original comment by charles....@gmail.com on 20 Mar 2009 at 3:18

[GoogleCodeExporter]

Looking at the AppleEvents 3.1.1 supports, I see differences in a number of 
commands
and properties in the sdef.

- floatontop
- repository url
- screenshot
- user interaction level
- input source
- repeats
- location
- enter full screen
And a new command has been added:
- clear EPG database

I wonder whether these changes to AppleEvent support are related to what we're 
seeing.

Original comment by charles....@gmail.com on 20 Mar 2009 at 8:51

[GoogleCodeExporter]

I can confirm the beahviour after the eyeTY update to 3.1.1:
Closed windows of recordings will re-open again & flickering.

Original comment by mhema...@gmail.com on 21 Mar 2009 at 8:49

[GoogleCodeExporter]

same here. 
Please Fix it, I can't look TV. ;-)

Original comment by mario.at...@googlemail.com on 21 Mar 2009 at 5:25

[GoogleCodeExporter]

Same problem here

Original comment by oliver.m...@gmail.com on 22 Mar 2009 at 10:05

[GoogleCodeExporter]

same problem for me as well - makes it unusable.

Original comment by crandy1...@gmail.com on 22 Mar 2009 at 4:02

[GoogleCodeExporter]

Same problem for me!

Original comment by jens.him...@gmail.com on 22 Mar 2009 at 10:53

[GoogleCodeExporter]

Keep in mind you can roll back to 3.1 using

  eyetv://checkforupdates?build=4513

Elgato support maintains an up-to-date list of EyeTV 3 roll-back links at:

  http://support.elgato.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=3074

Original comment by charles....@gmail.com on 23 Mar 2009 at 2:31

[GoogleCodeExporter]

Can anyone confirm that these problems don't occur in 3.1?

I personally haven't upgraded to 3.1 b/c I didn't like the EPG implications of 
that
release.

Charles, you seem to be somewhat python savvy,  if you wouldn't mind, could you 
fire
up a terminal and try this:

$ cd /System/Library/CoreServices/Front\
Row.app/Contents/PlugIns/EyeTV.frappliance/Contents/Resources/

$ python
>>> import appscript
>>> appscript.app("EyeTV").enter_full_screen()

and tell me the results?  That'll be critical for fixing the full screen issue.

-Jon

Original comment by jon.chri...@gmail.com on 23 Mar 2009 at 4:32

[GoogleCodeExporter]

Jon,

If Charles doesn't get there first I'll run the commands you ask tonight. I can 
confirm that EyeTV 3.1.1 broke my installation as described above. 

I had some issues rolling back to EyeTV 3.1 - when trying to leave a playing 
recording by pressing "Menu", the grey spinning spoke wheel would display then 
freeze. If I hit menu a few more times I'd get dumped back out at the Desktop. 
Alternatively if I killed Front Row I'd get back there too. This seemed 
consistent 
behaviour. I managed to fix it by updating the PyeTV.py / PyeTVMetaData.py / 
PyeTVWaitController.py files to the r53 versions (26th October 2008) from the 
svn 
repository; I think these were checked in after the 1.2 release date?

I was fairly sure that I had EyeTV 3.1 before it was upgraded to 3.1.1, so am 
at a 
loss to why it was broken when I downgraded to 3.1 (build 4515) again. Perhaps 
the 
3.1.1 installation overwrote a file not replaced by the downgrade to 3.1.

Anyway, the system.log when I fired up Front Row, selected EyeTV (3.1), played 
a 
program then hit "Menu" is included below.

I'll get back on the python command line test with 3.1.

Mar 22 22:50:30 xxx FrontRow[369]: ******** Application Startup ********
Mar 22 22:50:33 xxx Front Row[369]: +[SapphireAppliance className] called for 
Leopard/ATV2 whitelist check, so I'm lying, m'kay?
Mar 22 22:50:33 xxx FrontRow[369]: T:[0xa00c2720] Registered BRPhotoPlayer for 
media 
type 3
Mar 22 22:50:33 xxx FrontRow[369]: T:[0xa00c2720] Registered 
FRITunesAppMusicPlayer 
for media type 0
Mar 22 22:50:33 xxx FrontRow[369]: T:[0xa00c2720] Registered FRVideoPlayer for 
media 
type 1
Mar 22 22:50:33 xxx FrontRow[369]: T:[0xa00c2720] Registered FRDVDPlayer for 
media 
type 2
Mar 22 22:50:38 xxx FrontRow[369]: T:[0xa00c2720] Start up render thread for 
display: 
0x764b8000
Mar 22 22:50:46 xxx Front Row[369]: RUIPythonAppliance: ************ PyeTV 
Starting 
**********************************
Mar 22 22:50:53 xxx FrontRow[369]: T:[0xa00c2720] Stop render thread
Mar 22 22:50:52 xxx com.apple.RemoteUI[369]: Front Row: unknown type name 
"furl".
Mar 22 22:50:52 xxx com.apple.RemoteUI[369]: Front Row: unknown type name 
"constant".
Mar 22 22:50:52 xxx com.apple.RemoteUI[369]: Front Row: unknown type name 
"cURL".
Mar 22 22:50:59 xxx FrontRow[369]: T:[0xa00c2720] Start up render thread for 
display: 
0x764b8000
Mar 22 22:51:46 xxx com.apple.launchd[167] (com.apple.RemoteUI[369]): Exited 
abnormally: Hangup <-- kill -hup on Front Row at command line

-Stuart

Original comment by stubi...@gmail.com on 23 Mar 2009 at 10:16

[GoogleCodeExporter]

Rookie error, how do I get appscript on the path.

$ pwd
/System/Library/CoreServices/Front 
Row.app/Contents/PlugIns/EyeTV.frappliance/Contents/Resources

$ head etv.py
import objc
import Foundation
import AppKit
from appscript import *

$ python
Python 2.5.1 (r251:54863, Apr 15 2008, 22:57:26)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import AppKit
>>> import appscript
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named appscript

Original comment by stubi...@gmail.com on 23 Mar 2009 at 1:46

[GoogleCodeExporter]

Dang, I was hoping that would work and users wouldn't have to install appscript.
I'm not at my mac at the moment, but there is a separate program called python 
in

/System/Library/CoreServices/Front\
Row.app/Contents/PlugIns/EyeTV.frappliance/Contents/MacOS

Perhaps if you run

./python in that directory it will pick up the appscript bundled with pyetv. 
Otherwise you'll have to install it from http://appscript.sourceforge.net/

Original comment by jon.chri...@gmail.com on 23 Mar 2009 at 4:30

[GoogleCodeExporter]

OK, managed to get it going by clearing the sys.path and setting it to what was 
in the info.plist:

$ pwd     
/System/Library/CoreServices/Front 
Row.app/Contents/PlugIns/EyeTV.frappliance/Contents/MacOS

$ ./python
Python 2.5.1 (r251:54863, Apr 15 2008, 22:57:26) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path = ['']
>>> sys.path.append("/System/Library/CoreServices/Front 
Row.app/Contents/PlugIns/EyeTV.frappliance/Contents/Resources/lib/python2.5")
>>> sys.path.append("/System/Library/CoreServices/Front 
Row.app/Contents/PlugIns/EyeTV.frappliance/Contents/Resources/lib/python2.5/lib-
dynload")
>>> sys.path.append("/System/Library/CoreServices/Front 
Row.app/Contents/PlugIns/EyeTV.frappliance/Contents/Resources/lib/python2.5/site
-packages.zip")
>>> import appscript
>>> appscript.app("EyeTV").enter_full_screen()

If I had a recording playing in a window at the time of executing 
enter_full_screen this had the effect of 
sending the playback window fullscreen. I guessed at 
appscript.app("EyeTV").exit_full_screen() and this 
behaved as you would expect too.

HTH,
-Stuart

Original comment by stubi...@gmail.com on 23 Mar 2009 at 8:39

[GoogleCodeExporter]

That was on 3.1 (b4515) of eyetv btw. I can potentially try 3.1.1 but after the 
last disaster would like to clone my 
volume first.

Original comment by stubi...@gmail.com on 23 Mar 2009 at 8:56

[GoogleCodeExporter]

I've tried the call on 3.1.1 and it doesn't work:

>>> appscript.app("EyeTV").enter_full_screen()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "build/bdist.macosx-10.5-i386/egg/appscript/reference.py", line 511, in __getattr__
AttributeError: Unknown property, element or command: 'enter_full_screen'

Now the weird bit is if I load up the EyeTV 3.1 dictionary into Script Editor I 
see "enter full screen" as a method 
under "EyeTV Suite"; there is also a method "exit full screen". If I do the 
same with 3.1.1, there is not the 
method "enter full screen". The method "exit full screen" does still exist. 
Strangely, 3.1.1 does have a method 
called "c" (with no description) that appears to behave in the same way as 
"enter full screen". What is going 
on?

Original comment by stubi...@gmail.com on 24 Mar 2009 at 11:29

[GoogleCodeExporter]

I just got confirmation from an Elgato engineer that the applescript is broken
in 3.1.1.  It has been internally fixed, but not released yet.

Given that PyeTV talks to EyeTV exclusively via applescript, I'll have to wait 
for 3.1.2.

Thanks for all the help running this down; sorry I couldn't resolve it.

I'm leaving the bug open for now, just to prevent duplicate entries which tend 
to
happen after a bug is closed on google code, as for some reason people don't 
think to
search for closed bugs on their issue.

Original comment by jon.chri...@gmail.com on 26 Mar 2009 at 1:16

• Changed state: Accepted

[GoogleCodeExporter]

Issue 25 has been merged into this issue.

Original comment by jon.chri...@gmail.com on 1 Jul 2009 at 6:14

[GoogleCodeExporter]

Issue 28 has been merged into this issue.

Original comment by jon.chri...@gmail.com on 1 Jul 2009 at 6:14

[GoogleCodeExporter]

I had the problem with EyeTV 3.1.1 and so reverted to EyeTV 3.1. This worked 
well.
Then EyeTV 3.1.2 came out so I updated - big mistake! Now Front Row crashes 
when I
select EyeTV from the Front Row menu! 
I will try to revert back to EyeTV 3.1 for my home entertainment system.

Original comment by mpa...@tpgi.com.au on 1 Jul 2009 at 7:03

[GoogleCodeExporter]

Reverting to EyetV 3.1 did not work (still gave an error message saying restart 
Front
Row) so I updated to 3.1.2 again. Then I trashed Front Row preferences and 
repaired
permissions and EyeTV selection from Front Row now seems to work OK.

Original comment by mpa...@tpgi.com.au on 3 Jul 2009 at 2:24

[GoogleCodeExporter]

Mpaine

does pyetv work now?

Original comment by jon.chri...@gmail.com on 3 Jul 2009 at 4:07

[GoogleCodeExporter]

After upgrading to EyeTV 3.1.2, I am finding that pyetv is now working as 
expected. Full-screen content through 
Front Row seems to click through a couple more screens than I remember from 
EyeTV 3.1, but after a few 
moments, everything plays correctly.

Original comment by mmcc...@gmail.com on 3 Jul 2009 at 2:08

[GoogleCodeExporter]

EyeTV 3.1.2 Fixed this issue.

Original comment by jon.chri...@gmail.com on 18 Aug 2009 at 5:30

• Changed state: Done

[GoogleCodeExporter]

Thanks!

Original comment by emailtod...@gmail.com on 18 Aug 2009 at 9:34