Client shows default layout even if Interleave unticked ?

Server now always sends the default and will play it if set to interleave or if there is no other valid layout. I guess you have media missing.

Alex

This email carries a disclaimer, a copy of which may be read at http://learning.longhill.org.uk/disclaimer

But correct layout is also presented, so why You guess that is something related to media?

Both clients with same shedule record (multiple ticks in same entry in calendar:

----------------

Broken client:

Sep 11 18:04:10 10.168.100.112 XiboClient[404]: Info: Checking if a new schedule is available
Sep 11 18:04:20 10.168.100.112 XiboClient[404]: Schedule Timer Ticked at 2010-09-11 18:04:20. There are 2 items in the schedule.
Displays both layouts in a row - default, correct, default, correct...

Shedule requested by SoaoUI:

<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="urn:xmds" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
   <SOAP-ENV:Body>
      <ns1:ScheduleResponse>
         <ScheduleXml xsi:type="xsd:string"><![CDATA[<?xml version="1.0"?>
<schedule>
  <layout file="166" fromdt="2000-01-01 00:00:00" todt="2030-01-19 00:00:00" scheduleid="" priority="0"/>
  <layout file="242" fromdt="2010-09-02 10:00:00" todt="2010-10-01 10:00:00" scheduleid="581" priority="0"/>
  <default file="166"/>
</schedule>]]></ScheduleXml>
      </ns1:ScheduleResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

----------------

Correct client:
Sep 11 18:06:17 10.168.247.150 XiboClient[15408]: Info: Checking if a new schedule is available
Sep 11 18:06:27 10.168.247.150 XiboClient[15408]: Schedule Timer Ticked at 2010-09-11 18:06:27. There are 1 items in the schedule.
Displays only correct record.

Shedule requested by SoaoUI:

<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="urn:xmds" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
   <SOAP-ENV:Body>
      <ns1:ScheduleResponse>
         <ScheduleXml xsi:type="xsd:string">&lt;?xml version="1.0"?>
&lt;schedule>
  &lt;layout file="242" fromdt="2010-09-02 10:00:00" todt="2010-10-01 10:00:00" scheduleid="581" priority="0"/>
&lt;/schedule></ScheduleXml>
      </ns1:ScheduleResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

----------------

In calendar both clients looks totally same.
And problably something unrealted but interesting: why there is &lt;schedule> in second one, something broken?

From your broken client request:
<schedule>
  <layout file="166" fromdt="2000-01-01 00:00:00" todt="2030-01-19 00:00:00" scheduleid="" priority="0"/>
  <layout file="242" fromdt="2010-09-02 10:00:00" todt="2010-10-01 10:00:00" scheduleid="581" priority="0"/>
  <default file="166"/>
</schedule>

The client's doing exactly what it's told. Default layout is 166 and it's also in the schedule which means that interleave is ticked.

<schedule>
  <layout file="242" fromdt="2010-09-02 10:00:00" todt="2010-10-01 10:00:00" scheduleid="581" priority="0"/>
</schedule>

That reply isn't valid from a 1.2.0-rc2 server. It will always have a <default/> node - so what version generated that?

Alex

I know that client doing what servers told to it, that why i'm saying thats some manfulction in server :)

Server is rc2 ofcourse, both clients configured with unticked interleave default layout (166) and only 242 in sheduler.

There is same error in other layouts/schedules randomly. Was there in rc1 already - client was playing default included by rc1 server, when there interleaver was unticked.

In that case I suggest your database is in someway hosed. If it was doing it on RC1 then there's no reason to suspect that we'd have fixed anything in RC2 if you didn't tell us!

If you send over your database I'll take a look and see if it's something simple.

Alex

Yes, i did't suspected that it would be fixed in rc2, but i've spotted it day after rc1 so report from rc1 probably was already outdated - i've expected answer to update to rc2 first and that was possible today :)
Problem was not very important as default is 5secs splashscreen :)
Just doublechecked that all files were overwritten correctly so as i expected (and as you're guessing) its another db bug produced by rc1 :)
So i'll produce db dump now :)

I've sent dump some time ago.
Plase let me know if you got it.

Hello Alex,

today i've again spotted that some terminals uses default layout.

So i've checked db and invoked delete again:
Database changed
mysql> delete from schedule_detail where ToDT = 2556054000;
Query OK, 92 rows affected (0.03 sec)

mysql> select count(*) from display;
+----------+
| count(*) |
+----------+
| 102 |
+----------+

One more, there definitly weren't different 92 online clients since last delete, so those records were duplicated for some screens...

Or maybe not, i've assumed that errors are produced for online clients only, don't know why :)

There's no code that I can think of that would alter the schedule in the webservice - so we're looking at the schedule code or changing default layout.

What's the common factor on those displays? Have they had new content added/removed or their default layouts changed since you last ran the query?

Can you run the query, then change schedule and then run again to see if there's a new record to delete? Then repeat but change the default.

Cheers

Alex

Ok, i see when those records are produced - editing display name is enough to produce some new records to drop :)
No layout/schedule changes were made since last week, but almost all clients names were changed.
Just changed one more name to check it and there it is:

mysql> delete from schedule_detail where ToDT = 2556054000;
Query OK, 1 row affected (0.00 sec)

OK -thanks for all your help on this. I've converted it to a bug.

It should be simple enough to add that SQL to the 1.2.0 upgrade script to fix any broken displays for other people too.

Cheers

Alex

Nice to read that we've sorted next thing up. Thanks for your help too :)

Hey there Bartek and Alex,

I've read through the above conversation and I think I have the same issu; clients that will display the default lay-out although the option 'standard interleave' isn't ticked.

Now I can't exactly get what your solution is but any help is appreciated.

Greetz
Roel

If you're running a recent version of Xibo the default layout will be shown
when all other content is invalid (ie being downloaded from the server
because its been modified)

Alex