windows 8 & Phoenix

[stuckless]

I spent some time last night going through the menu code (which is where this appears to get stuck on, based on the logging), but I can't see any reason why when loading a menu into memory, it would case the system to hang.

When you start a client, are you running it as a service, or as a normal user? Is there any indication that Windows is requesting your permission to authorize an action? ie, create a directory, open a url, etc? In my limited experience with windows I've been burned a few times "waiting" for something only to realize that there is an icon in the task bar that is requiring my attention before the process will continue. I've found all too often that when windows requires your attention it doesn't pop up a dialog, but rather is just adds a new icon to the taskbar and then waits for you to realize that something isn't working right.

[sflamm]

I had thought of the exact same thing... UAC was on normal settings and there were no background requests for confirmation that I could see. Also my user is in the admin group...

Not sure what would be particular to Phoenix that would require admin confirmation - as it is the only item in SageTV that hangs..

I will try to setup a new machine (the other one is now in action using 409 - so I would hate to disturb it) and get the log files for you.

[stuckless]

Originally Posted by sflamm

I had thought of the exact same thing... UAC was on normal settings and there were no background requests for confirmation that I could see. Also my user is in the admin group...

Not sure what would be particular to Phoenix that would require admin confirmation - as it is the only item in SageTV that hangs..

I will try to setup a new machine (the other one is now in action using 409 - so I would hate to disturb it) and get the log files for you.

I do know that when phoenix starts it will try to create some directories under the SageTV home... and that might force a UAC prompt, not sure. It also may attempt to download the updated x-vfs.xml file from the internet, if it is missing, and that might prompt another requrest, not sure. Again, I don't know much about windows uac, just that most times I don't notice it right away

[Gustovier]

Did anybody ever figure this out? I'm installing onto a new client box I built and I am running into this scenario as well. The only way I can resolve is to wipe out my client .properties file but eventually it just happens again...

Never had this issue on extenders, or on the server (when I do run it on the server, which is pretty rare)

Also i'm running the 1 version prior to the latest on the extenders, not sure if that makes a difference

[Gustovier]

One other thing, I'm still on windows 7.

I have noticed, that if I'm using the standard STV and load phoenix, all is well. I can get one restart out of the sagetv client. But after that first restart all subsequent restarts of the client result in this issue. It's a hung thread, but I can't really tell whats happening. I probably need to take a java core and look at the stack trace...

Update:

I take that back. Once I load Phoenix from the default stv, I can keep it running and everything seems fine until I restart the sage client. I'm used to just sending a kill -3 to get a java core and it looks to not be that easy in windows. I'm not quite sure what to do next. Is there a way to step through a stv load as sage client starts up?

Update 2:

Ok, so I was up late last night building this client. Woke up refreshed and got a chance to do some more searching around the forum. I just uninstalled everything. Then used Stuckless's tool to install phoenix and its dependecies. That resolved the issue. So it must have been a bad install on Sage's part (or most likely my permissions from the base install). The only issue I see with this is that the plugin manager has no idea that phoenix or any of its dependencies are installed. So no update notifications within Sage. I probably could still install from within Sage and then just use the updater to override.

[sflamm]

i've reinstalled all the dependencies - still exhibits the same behavior. the problem is related to phoenix... old versions of phoenix do not exhibit the behavior at all.

as far a i know - no one has solved it yet.

[stuckless]

Originally Posted by Gustovier

Ok, so I was up late last night building this client. Woke up refreshed and got a chance to do some more searching around the forum. I just uninstalled everything. Then used Stuckless's tool to install phoenix and its dependecies. That resolved the issue. So it must have been a bad install on Sage's part (or most likely my permissions from the base install). The only issue I see with this is that the plugin manager has no idea that phoenix or any of its dependencies are installed. So no update notifications within Sage. I probably could still install from within Sage and then just use the updater to override.

You'll probably want to install Phoenix via the plugin manager so that plugin classes get loaded by SageTV. If you don't then things like automatic metadata lookup will not work.

If you install via the plugin manager and it stops working, then it may be something in the phoenix plugin initialization... Again, I've looked through the code, but I can't see where/why it would be failing... and only for a client setup.

Originally Posted by sflamm

i've reinstalled all the dependencies - still exhibits the same behavior. the problem is related to phoenix... old versions of phoenix do not exhibit the behavior at all.

as far a i know - no one has solved it yet.

I'm not even sure how to troubleshoot this... it's like a needle in a haystack. As I mentioned before... when Phoenix starts it will check for missing vfs files (and download them if necessary) and it may configure the weather from the existing configured weather from the default stv... but in last few releases, there haven't been a lot of changes that would cause they behaviour that you are seeing.

[sflamm]

I'm not even sure how to troubleshoot this... it's like a needle in a haystack. As I mentioned before... when Phoenix starts it will check for missing vfs files (and download them if necessary) and it may configure the weather from the existing configured weather from the default stv... but in last few releases, there haven't been a lot of changes that would cause they behaviour that you are seeing.

I really appreciate your taking the time to investigate. As always happy to help pin point the issue if there is anything I can do on my end. As you can tell - there are a number of reported incidences now so there must be something in common. Let me know if there is something I can do to further help track it down.

Out of curiosity, are there major improvements that I am missing by running 409 instead of the latest? Not sure if I have seen a change list lying around.

[Gustovier]

Originally Posted by stuckless

You'll probably want to install Phoenix via the plugin manager so that plugin classes get loaded by SageTV. If you don't then things like automatic metadata lookup will not work.

If you install via the plugin manager and it stops working, then it may be something in the phoenix plugin initialization... Again, I've looked through the code, but I can't see where/why it would be failing... and only for a client setup.

Welp, as you suggested, I tried installing via the plugin manager over my working phoenix install that was done with your utility. That cause the issue to re-appear. I then tried to use your utility again, and that also does not resolve. So I'm thinking I have to manually remove phoenix and its dependices via the plugin manager and try your utility again.

One thing I also noticed is that scrolling through the guide is slow/sluggish. On the extenders this works pretty fast. I'll start another topic to cover this.

[Gustovier]

Originally Posted by sflamm

I really appreciate your taking the time to investigate. As always happy to help pin point the issue if there is anything I can do on my end. As you can tell - there are a number of reported incidences now so there must be something in common. Let me know if there is something I can do to further help track it down.

Out of curiosity, are there major improvements that I am missing by running 409 instead of the latest? Not sure if I have seen a change list lying around.

sflamm,

what was the procedure you took with getting phoenix up and running on your client?

[sflamm]

install phoenix using the plugin installer (inside SageTV).
then replace the jars etc with the ones from the Phoenix 409 install (overwrite).
they can all be found on the phoenix source site

[sflamm]

Really want to take advantage of the new JPG meta data - sure it speeds things up in addition to reducing storage...

How can we localize this bug and fix?

[stuckless]

I'm wondering if someone wants to try this...

1. remove STVs/Phoenix/menus/OptionsMenu.xml
2. Start Sage

I've gone through the initialization of Phoenix, and I can't find anything that I can do for "debugging", since every system is required. But given the logs show that the OptionsMenu.xml was the last thing it didn't complete, then I thought that perhaps we should start with removing it.

Post your results, when you've tested.

Thanks,

[sflamm]

Thanks for taking the time to debug this!

Here are the results:

Loaded fresh SageTV, installed Phoenix and loaded Phoenix STV. After restart SageTV/Phoenix hangs (as usual). See log file attached. Fails as you stated on "OptionsMenu.xml"

Followed your directions. First restarted SageTV with default STV. Then stopped SageTV and removed "OptionsMenu.xml". Restarted SageTV and loaded Phoenix STV. Now upon restart Phoenix loads successfully (no hang)

Looks like you have isolated the cause. What can I do to help you debug the OptionsMenu.xml?

[sflamm]

I've isolated the xml stanza that is the problem:

 <menu name="phoenix.menu.options.admin" label="Admin Tools">
                  <menuItem label="${&quot;Change User (&quot; + phoenix_api_GetUserProfileName( phoenix_api_GetCurrentUserProfile() ) + &quot;)&quot;}" visible="true">
                        <eval>AddGlobalContext( "OptionsSubmenu" , "ChangeUser" )</eval>
                        <eval>Refresh()</eval>
                  </menuItem>
                  <menuItem label="Load STV" visible="true">
                        <eval>CloseOptionsMenu()</eval>
                        <eval>ExecuteWidgetChainInCurrentMenuContext("PHNX-264074")</eval>
                  </menuItem>
                  <menuItem label="Reload Default UI" visible="true">
                        <eval>AddGlobalContext("gCurCustomSTVFilePath", null )</eval>
                        <eval>AddGlobalContext("gTargetMenuName", null)</eval>
                        <eval>AddGlobalContext("gReloadCustomSTVOnHome", null)</eval>
                        <eval>AddGlobalContext("gReloadCustomSTVWithoutConfirm", null)</eval>
                        <eval>LoadSTVFile(GetDefaultSTVFile())</eval>
                  </menuItem>
                  <menuItem label="Update Phoenix" visible="false">
                        <eval>phoenix_beta_UpdatePhoenix()</eval>
                  </menuItem>
            </menu>

If I remove this stanza Phoenix loads just fine.

Put it back and Bam! problem again.

[sflamm]

It looks like this line is the issue:

<eval>AddGlobalContext("gReloadCustomSTVWithoutConfirm", null)</eval>

[stuckless]

Originally Posted by sflamm

It looks like this line is the issue:

Just curious... but what makes you think it's that line specifically. The reason I ask is that <eval> statements are only evaluated when the menu item is selected, and never during startup. So I'm having a hard time seeing how that particular line could cause a problem.

Having expressions (ie, ${SomeCode} ) in the label can be executed during loading, if getLabel() is called on the menu/item, but not the <eval> statements.

In the previous log file, I was also seeing the the UI Context was using the LOCAL UI context, and I'm not sure if that is normal or not (or if it might be part of the issue)

[sflamm]

I thought I'd isolated it by simply removing each menu item within the "Admin Tools" menu one by one.

However, just tried it again and it is hanging. So looks like I was mistaken.

But the issue is definitely specific to the "Admin Tools" menu. After the hang I just removed the entire "Admin Tools" menu from the OptionsMenu.xml again it works fine without it.

Attaching the latest phoenix log for your review and the current OptionMenu.xml (working).

[sflamm]

Ok - looks like this is the issue (hopefully right this time):

<menuItem label="${&quot;Change User (&quot; + phoenix_api_GetUserProfileName( phoenix_api_GetCurrentUserProfile() ) + &quot;)&quot;}" visible="true">
                        <eval>AddGlobalContext( "OptionsSubmenu" , "ChangeUser" )</eval>
                        <eval>Refresh()</eval>
                  </menuItem>

Attaching phoenix logs with and without.

[sflamm]

Can you add some debug code to the phoenix_api_GetUserProfileName() method?