News:

Latest versions:
Server plugin: 0.5.1
MVP dongle: 0.5.2
Raspberry Pi client: 0.5.2
Windows client: 0.5.2-1

Main Menu

Vomp 0.3.1 Teletext

Started by AndersF, July 18, 2009, 20:50:26

Previous topic - Next topic

MartenR

Can you please test, if it helps to set in teletextdecodervbiebu.cc
in the lines :
if (dirty && txtview!=NULL ) {
       
        if ( !renderfirstlineonly) {
            Message* m= new Message();
            m->message = Message::TELETEXTUPDATE;
            m->to = txtview;
            m->from = this;
            m->parameter = 0;
            Command::getInstance()->postMessageFromOuterSpace(m);
        } else if (firstlineupdate==10) {
            Message* m= new Message();
            m->message = Message::TELETEXTUPDATEFIRSTLINE;
            m->to = txtview;
            m->from = this;
            m->parameter = 0;
            Command::getInstance()->postMessageFromOuterSpace(m);
            firstlineupdate=0;
        } else firstlineupdate++;
       
       
    }
]



firstlineupdate==10) to smaller value than 10.

Marten

AndersF

Hi,

I believe I've tried firstlineupdate==5, but I'm not sure how to re-compile an build a new dongle!
I used makedevenv-5 to do initial build, and after patching. It seems do download and recompile everything.

How can I patch and rebuild dongle without the need to download and build from scratch?

/Anders

AndersF

As far as I can tell running makedevenv again recompiles a new dongle. (the modified .cc file is still there and a new .o file is created.)
I can see no change for neither the ==5 or ==1 comparison.

Anders

Chris

To try modified code all you need to do is run "make release" in the client directory and then "autobuild" in the dongle directory. That is enough to build a new dongle.

MartenR

@Anders
Well it should update the teletext more and so it might be more responsive.
Maybe choose an bigger value...

Marten

AndersF

A higher value works better. I've tried 17, 20 and 22. I've got a hangup at 17. 22 seem to work at least as good as 20.
I've seen occasional flickering screens.
The text at the top and right of the screen is slightly cut.

Otherwise it works OK.

/Anders

MartenR

@AndersF
Good news, although I though it would be the other way round, it seems that vomp has a problem with to frequent screen updates.
QuoteThe text at the top and right of the screen is slightly cut.
You can change in vteletextview.cc the numbers in the lines
   78
   79     if (Video::getInstance()->getFormat() == Video::PAL)
   80     {
   81         //setSize(680, 550);
   82         setSize(680,22); //Only first line
   83         setPosition(40, 26);
   84     }
   85     else
   86     {
   87         setPosition(40, 30);
   88         //setSize(680, 450);
   89         

in the setposition function to adjust the position of the teletext. Try out and tell us the right values.(This depends on your tv set, on mine everything was visible). Anyway, after the changes do ttxt subtitle with the green button work?

Marten

AndersF

Hi again,

I've tried out some values that seem to work reasonably good.

if (Video::getInstance()->getFormat() == Video::PAL)
    setPosition(40, 31);

and

       } else if (firstlineupdate==30) {

For the subtitle It works like this for SVT2 of Sweden:

The green button gives  two choices, for example 691, and 8ff. When selecting one of them there is no subtitle shown and the there will likely be a hangup, like previously for teletext with "firstlineupdate==10".
However, for sub-title I'm used to choose teletext and page 299 for SVT. This works for the Vomp as well, so one can say that sub-title works to some extent.


When the hangup occurs there seems to be a busy loop with the printouts below. This is similar to the printout during the hangup that occurs when "firstlineupdate==10"

/Anders

21:43:42.901128 [debug]  1002 Core - SIGURG caught
21:43:42.924003 [debug]  1002 BoxStack - Update called
21:43:42.924819 [debug]  1002 BoxStack - Locked for update
21:43:42.928701 [debug]  1002 BoxStack - Unlocked for update
21:43:42.929506 [debug]  1002 Command - processing message 32
21:43:42.930285 [debug]  1002 Command - Sending message to boxstack
21:43:42.931061 [debug]  1002 BoxStack - sending message from box 0x102517c8 to box 0x10271a68 32
21:43:42.983941 [debug]  1016 Command - PMFOS called
21:43:42.984837 [debug]  1016 Command - PMFOS called
21:43:42.985934 [debug]  1016 Command - PMFOS called
21:43:42.986913 [debug]  1016 Command - PMFOS called
21:43:42.987757 [notice] 1002 Core - Signal 23 received
21:43:42.988693 [debug]  1002 Core - SIGURG caught
21:43:43.077008 [debug]  1016 Command - PMFOS called
21:43:43.078164 [notice] 1002 Core - Signal 23 received
21:43:43.078976 [debug]  1002 Core - SIGURG caught
21:43:43.163042 [debug]  1016 Command - PMFOS called
21:43:43.163946 [debug]  1016 Command - PMFOS called
21:43:43.168788 [notice] 1002 Core - Signal 23 received
21:43:43.169725 [debug]  1002 Core - SIGURG caught
21:43:43.194140 [debug]  1016 Command - PMFOS called
21:43:43.195174 [notice] 1002 Core - Signal 23 received
21:43:43.196110 [debug]  1002 Core - SIGURG caught
21:43:43.284060 [debug]  1016 Command - PMFOS called
21:43:43.285081 [debug]  1016 Command - PMFOS called
21:43:43.285639 [debug]  1016 Command - PMFOS called
21:43:43.286472 [debug]  1016 Command - PMFOS called
21:43:43.287320 [notice] 1002 Core - Signal 23 received
21:43:43.288256 [debug]  1002 Core - SIGURG caught
21:43:43.373659 [debug]  1016 Command - PMFOS called
21:43:43.374805 [debug]  1016 Command - PMFOS called
21:43:43.375829 [notice] 1002 Core - Signal 23 received
21:43:43.376635 [debug]  1002 Core - SIGURG caught
21:43:43.584509 [debug]  1016 Command - PMFOS called
21:43:43.584993 [debug]  1016 Command - PMFOS called
21:43:43.585820 [debug]  1016 Command - PMFOS called
21:43:43.586911 [debug]  1016 Command - PMFOS called
21:43:43.587873 [notice] 1002 Core - Signal 23 received