AttributeError: XiboDisplayManager instance has no attribute 'scheduler'

Asked by Michel van der Breggen

I get this error when I start Xibo Pyhton Client.

[13-02-15 09:08:09.239] DEPRECATION: XiboClient.py:4240: Node.setEventHandler() deprecated since version 1.7. Use Node.subscribe() instead.
[13-02-15 09:08:10.013] WARNING: Using framerate of 60 instead of VBRate of 1
[13-02-15 09:08:11.101] WARNING: Could not find font face Arial. Using sans instead.
Exception in thread Thread-3:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
    self.run()
  File "XiboClient.py", line 1583, in run
    self.parent.nextLayout()
  File "XiboClient.py", line 3979, in nextLayout
    self.currentLM = XiboLayoutManager(self, self.Player, self.scheduler.nextLayout())
AttributeError: XiboDisplayManager instance has no attribute 'scheduler'

The first error is just because Xibo is not LibAVG 1.7.1 compatible. But the second is the one that gives me problems. Because of the error no schedule is being loaded and I am looking at a blank screen.

Question information

Language:
English Edit question
Status:
Answered
For:
Xibo Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Alex Harrington (alexharrington) said :
#1

Is that from the binaries we provide? Because I'm running with 1.7.1 and I don't think I've seen that deprication warning before.

In any case are you certain there's no modifications to the Xibo code? Because it looks like the client is trying to run a layout before the scheduler has initialised which shouldn't be possible.

Alex

Revision history for this message
Michel van der Breggen (breggen) said :
#2

Hi Alex,
the binaries are from libavg for RPi. So the deprecated code is nothing I am really worried about. It is because libavg has changed the event handling routines, but they still support the old method.

The code of the XiboClient.py has only been altered in the fact that the eventhandlers have changed

            self.currentFH = self.player.setInterval(0, self.frameHandle)
            #self.currentFH = self.player.setOnFrameHandler(self.frameHandle)

I will change them back to see if this changes anything. But according to the libavg manuel this should be correct

Revision history for this message
Alex Harrington (alexharrington) said :
#3

Hi Michel

The frame handler is added and removed dynamically by the code so you'll need to update the other places where it's added and removed to ensure it's done correctly, otherwise the client will use way more CPU than needed.

Basically it only uses a frame hander when there is code on the queue waiting to be rendered.

If this is on RPi then I suspect it's probably a race condition that needs to be resolved. On a PC the startup probably happens far faster as there's more horsepower to handle the startup routine - so try looking at the point where the DisplayManager is started and see if you can see where the race comes from?

Patches appreciated.

Alex

Revision history for this message
Michel van der Breggen (breggen) said :
#4

Working on the scheduler thing, but I seem to be getting the first screen from my design. Second screen is a movie which is very very slow. Which method do you use for showing movies, because it doesn't use any form of hardware acceleration.

Another problem I am running into is this message :

 (.frameHandle:4492) 1 error A runtime error occured: Can't insert a node of type browser into a node of type div.

Which is when I want to render my text. No clue as where is comes from. But my text doesn't show up on screen and the design doesn't progress to the next slide either.

Any ideas would be welcome.

Revision history for this message
Alex Harrington (alexharrington) said :
#5

The video playback is done by libavg so that question is probably best directed to them. Video playback is certainly accellerated on PC hardware with libavg.

With the second issue, we use a plugin "browsernode" for libavg to render text/html etc. That's the part that's difficult to get built on arm etc as it involves compiling an ancient version of Chrome. I assume you've somehow managed that and have the plugin loaded? Or did you just comment out the line that loads the browser plugin?

Alex

Revision history for this message
Michel van der Breggen (breggen) said :
#6

Hi Alex,
I have been working on compiling chromium, berkelium, libbrowsernode and LibAVG on ARM for the past weeks. I have succeeded in compiling all of them working ( except for a small segfault while loading some types of jpegs ). Now the trick is to get it all working together.

That is the point I am currently working on and trying to figure out if any errors still exist. Xibo runs on the RPi, but it reacts slow and without libbrowsernode is only usable for showing images. When everything works according to spec Xibo should be completely functional on RPi.

Can you help me with the browser in div node error?

Revision history for this message
Alex Harrington (alexharrington) said :
#7

Hi Michel

I'm a Python coder. All I can tell you is either the plugin for browsernode isn't there (or it's non-functional) or the definition for it has become invalid as you certainly can put a browser node in a div. I'm afraid I don't have any real understanding of C++ or how this all works under the hood.

Best wishes

Alex

Revision history for this message
Michel van der Breggen (breggen) said :
#8

Hello Alex,
The error has been found in libbrowsernode. It seems that the only allowed parenttype of the browser node at this point is AVG self. I will update the code and recompile it. Let's hope that fixes the issue. At the same time I reported the issue to Andrea of libbrowsernode. Regards,Michel
 > To: <email address hidden>
> From: <email address hidden>
> Subject: Re: [Question #221954]: AttributeError: XiboDisplayManager instance has no attribute 'scheduler'
> Date: Fri, 15 Feb 2013 18:01:21 +0000
>
> Your question #221954 on Xibo changed:
> https://answers.launchpad.net/xibo/+question/221954
>
> Alex Harrington proposed the following answer:
> Hi Michel
>
> I'm a Python coder. All I can tell you is either the plugin for
> browsernode isn't there (or it's non-functional) or the definition for
> it has become invalid as you certainly can put a browser node in a div.
> I'm afraid I don't have any real understanding of C++ or how this all
> works under the hood.
>
> Best wishes
>
> Alex
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/xibo/+question/221954/+confirm?answer_id=6
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/xibo/+question/221954
>
> You received this question notification because you asked the question.

Revision history for this message
Alex Harrington (alexharrington) said :
#9

Thanks for the update, and for all your work on this so far

Revision history for this message
Michel van der Breggen (breggen) said :
#10

Hi Alex,
the error went away when i cleared my data directory. probably some stray data was left behind. Michel
 > To: <email address hidden>
> From: <email address hidden>
> Subject: Re: [Question #221954]: AttributeError: XiboDisplayManager instance has no attribute 'scheduler'
> Date: Sat, 16 Feb 2013 21:06:02 +0000
>
> Your question #221954 on Xibo changed:
> https://answers.launchpad.net/xibo/+question/221954
>
> Status: Open => Answered
>
> Alex Harrington proposed the following answer:
> Thanks for the update, and for all your work on this so far
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/xibo/+question/221954/+confirm?answer_id=8
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/xibo/+question/221954
>
> You received this question notification because you asked the question.

Revision history for this message
Alex Harrington (alexharrington) said :
#11

I've had a look at the scheduler error and basically if the machine fails to create an instance of the scheduler object within the time it takes for the splash screen to show and then transition out, you'll get the error you see now.

There's two approaches to fix it - one would be a complex locking arrangement where it's not possible for the layout to advance until the scheduler is instantiated. Or, I can prevent the splash screen showing at all until the download manager and scheduler are in place.

I think on balance it's probably better to use the second option as it keeps the code cleaner. I'll have a bash now and see if that creates any new problems. If it doesn't, a fix will be in 1.4.2

Cheers

Alex

Revision history for this message
Alex Harrington (alexharrington) said :
#12

I've pushed a patch up to:

lp:~alexharrington/xibo/pyclient-142

Can you give that a go and see if it fixes the scheduler race for you?

Thanks

Alex

Revision history for this message
Michel van der Breggen (breggen) said :
#13

Hello Alex,
I have tested your new version and I still can recreate the problem. But I also located that the problem is being caused by something within the data directory. I asume it has something to do with cached values. If you are interested I can send you the contents of the data directory. At this point the browsernode plugin has been updated and is being reviewed so this also works with the RPi, but I have another question you might be able to answer for me. When I change from one frame to the next, there is a small gap of black screen in between. Depending on what is next it is about 1 to 3 seconds. Is this normal with other installations or is there a slowdown in the fact that it takes more time to load the screen. I have looked at the code and I noticed that the next frame is being loaded when the previous frame is done. Maybe it is an idea to preload the next frame and display it when the previous frame ends. This could be a problem with some media type like video, music and flash. In those types you should be able to preload but not start until the frame is active. I have tested the framerate of libavg on the RPi and it is between 50 en 70 fps so that should be more then enough to swap screens without blackouts. If you need anything tested please let me know. With regards,
Michel P.S.
Is there a reason why xibo says version 1.5 when i download version 1.4.1 from bzr??
 > To: <email address hidden>
> From: <email address hidden>
> Subject: Re: [Question #221954]: AttributeError: XiboDisplayManager instance has no attribute 'scheduler'
> Date: Mon, 18 Feb 2013 13:31:01 +0000
>
> Your question #221954 on Xibo changed:
> https://answers.launchpad.net/xibo/+question/221954
>
> Status: Open => Answered
>
> Alex Harrington proposed the following answer:
> I've pushed a patch up to:
>
> lp:~alexharrington/xibo/pyclient-142
>
> Can you give that a go and see if it fixes the scheduler race for you?
>
> Thanks
>
> Alex
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/xibo/+question/221954/+confirm?answer_id=11
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/xibo/+question/221954
>
> You received this question notification because you asked the question.

Revision history for this message
Alex Harrington (alexharrington) said :
#14

If you could send over the data directory to <email address hidden> I'll see if I can see anything.

On reasonable hardware, you might get 1 or 2 black frames when changing between layouts. Certainly not seconds worth. You're correct you could pre-load some aspects of the layout in an off-screen canvas and swap it in at run time, but it actually makes transitions (which are implemented in versions going back to 1.1 and now in 1.5 server) hugely complicated to deal with.

If someone wanted to tackle that as a project with the aim of keeping the transition support we have working already as well as pre-loading layouts in offscreen canvases that would be great. Unfortunately I can't commit my resources to the client fully at the moment as there are so many issues with the version of Chrome that Berkelium provides it makes it a little pointless. For example today I've finally got to fixing webpage scaling to bring the Python client in line with the Windows client, only to find Chromium11 has a bug where scaling iframes doesn't work properly so we're back to where we were before again. Also the onPaint callback from Berkelium seems to fail randomly so the client has to repeatedly ask Berkelium to re-navigate to a URL to get any kind of usable output. If those issues were fixed then I'd be more inclined to start tuning what we have in more detail.

If you're getting 1.5 then you're pulling lp:xibo which is the development branch. If you want 1.4 then you need lp:xibo/1.4

Best wishes

Alex

Revision history for this message
Michel van der Breggen (breggen) said :
#15

Hi Alex,I am currently in the middle of tackling a few Berkelium problems myself, since it also gives me a few problems with segfaults. Reading around learns that Berkelium itself isn't very stable so I am trying to create a debug version of berkelium to see where the hell it goes wrong. I assume they cut some corners in memory usage. But when the debug version is ready I will spend some time looking at what they've done. In the meantime I upgraded the webkit to the latest version that supports 696 of chromium. I also upgraded libjpeg_turbo to the latest release so it will also build on an ARM device. When this is ready I will start reading up on Python ( I am more of a PHP,C++,C# user ) and look at the possibility of preloading. What I am thinking about should not break the transisions because you also transision on a loaded and rendered frame and not on a just initialised frame ( still loading and rendering ). So my idea is to load the next frame at start of the previous frame and keep it in memory till it goes over to the next frame. But I think it will be another week or so before I can start on that. Which branch should I work from? When the current compiling of berkelium is done I can copy the data directory ( build and use image are on different SD cards ) and mail it to you. Regards,
Michel
 > To: <email address hidden>
> From: <email address hidden>
> Subject: Re: [Question #221954]: AttributeError: XiboDisplayManager instance has no attribute 'scheduler'
> Date: Mon, 18 Feb 2013 22:06:10 +0000
>
> Your question #221954 on Xibo changed:
> https://answers.launchpad.net/xibo/+question/221954
>
> Status: Open => Answered
>
> Alex Harrington proposed the following answer:
> If you could send over the data directory to <email address hidden> I'll see
> if I can see anything.
>
> On reasonable hardware, you might get 1 or 2 black frames when changing
> between layouts. Certainly not seconds worth. You're correct you could
> pre-load some aspects of the layout in an off-screen canvas and swap it
> in at run time, but it actually makes transitions (which are implemented
> in versions going back to 1.1 and now in 1.5 server) hugely complicated
> to deal with.
>
> If someone wanted to tackle that as a project with the aim of keeping
> the transition support we have working already as well as pre-loading
> layouts in offscreen canvases that would be great. Unfortunately I can't
> commit my resources to the client fully at the moment as there are so
> many issues with the version of Chrome that Berkelium provides it makes
> it a little pointless. For example today I've finally got to fixing
> webpage scaling to bring the Python client in line with the Windows
> client, only to find Chromium11 has a bug where scaling iframes doesn't
> work properly so we're back to where we were before again. Also the
> onPaint callback from Berkelium seems to fail randomly so the client has
> to repeatedly ask Berkelium to re-navigate to a URL to get any kind of
> usable output. If those issues were fixed then I'd be more inclined to
> start tuning what we have in more detail.
>
> If you're getting 1.5 then you're pulling lp:xibo which is the
> development branch. If you want 1.4 then you need lp:xibo/1.4
>
> Best wishes
>
> Alex
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/xibo/+question/221954/+confirm?answer_id=13
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/xibo/+question/221954
>
> You received this question notification because you asked the question.

Revision history for this message
Alex Harrington (alexharrington) said :
#16

Thanks Michel

If you base your work on lp:xibo I think that would be best

Alex

Can you help with this problem?

Provide an answer of your own, or ask Michel van der Breggen for more information if necessary.

To post a message you must log in.