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

[Solved] Teletext not working

Started by hondansx, November 07, 2012, 18:56:18

Previous topic - Next topic

hondansx

Hi,

is this a known issue that the teletext is not working?
GA-EP43 | headless | 1xCineS2 Dual | 1xSkystar 2.6D | VDR 1.7.37 
Frontend: 1xRasperry | 1xION3

JTe

At least for me it used to work before the git updates of last weekend. I have not tested with the new updates and I will be next to my raspi client only in weekend, but I can test it then if nobody does it before!

MartenR

It is not a known is issue it should work.
I did not test it after the changes of the last weekend, but I can not remeber a change, that could break it.
So JTE please test it.

Marten

MartenR

Just tested it myself, it works.
You a note, if you are german like me and you are using a keyboard, vomp does not care about different keyboard layouts.
So yellow is y, which is the key labeled with a z.

Marten

hondansx

Quote from: MartenR on November 08, 2012, 07:01:23
Just tested it myself, it works.
You a note, if you are german like me and you are using a keyboard, vomp does not care about different keyboard layouts.
So yellow is y, which is the key labeled with a z.

Marten
Strange, is see the border line but no startpage is coming. Tested on different channels. I will try tonight again. Can I see whats going wrong in the logfile?
GA-EP43 | headless | 1xCineS2 Dual | 1xSkystar 2.6D | VDR 1.7.37 
Frontend: 1xRasperry | 1xION3

MartenR

QuoteCan I see whats going wrong in the logfile?
Only if simply the teletext pid is wrong or missing, otherwise it is not logged.
(Might depent on changes in VDR I am using an relative old vdr version.

Marten

hondansx

#6
Tested on my mvp and pi, tested with vdr-1.7.21/26/29/31, but no chance to get it working.
Number 100 do not count.
Any Ideas how I can debug this?

BTW: Which vdr-version are you using?
GA-EP43 | headless | 1xCineS2 Dual | 1xSkystar 2.6D | VDR 1.7.37 
Frontend: 1xRasperry | 1xION3

MartenR

I think 1.7.21, but I am not sure, but you have tested this before and after the change in vdr pid handling.
Well first do the following, check the entry in channel.conf, if the teletext pid is present (check also on the web, what the right pid should be).
Then look in the log there should be a entry stating the used pids (do not know if teletext is included, if not add this message).
If this is ok, look into demuxerts if teletxt packages arrives.
If they do not arrive, debug it, if they do you have to go into the decoder.

Hope this helps. (Probably there is a pid problem)

Marten

hondansx

Quote from: MartenR on November 09, 2012, 07:00:49
I think 1.7.21, but I am not sure, but you have tested this before and after the change in vdr pid handling.
Well first do the following, check the entry in channel.conf, if the teletext pid is present (check also on the web, what the right pid should be).
Then look in the log there should be a entry stating the used pids (do not know if teletext is included, if not add this message).
If this is ok, look into demuxerts if teletxt packages arrives.
If they do not arrive, debug it, if they do you have to go into the decoder.

Hope this helps. (Probably there is a pid problem)

Marten

It seems that the client gets the right pid, so I assume it is no vdr issue.


21:31:13.914790 [debug]  Client - Looking for channel 2::: number: 2 name: 'RTL Television'
21:31:13.914797 [debug]  Client - Found channel number 2, vpid = 163, apid1 = 104, tpid = 105


At which point in demuxerts can I see, if the packages arrives?

Output of  VTeletextView is:


14:04:20.931562 [ERR]    2688 VTeletextView - Start draw
14:04:20.931953 [ERR]    2688 VTeletextView - Line 0
14:04:20.932348 [ERR]    2688 VTeletextView - Line 1
14:04:20.932830 [ERR]    2688 VTeletextView - Line 2
14:04:20.933441 [ERR]    2688 VTeletextView - Line 3
14:04:20.934229 [ERR]    2688 VTeletextView - Line 4
14:04:20.935133 [ERR]    2688 VTeletextView - Line 5
14:04:20.939412 [ERR]    2688 VTeletextView - Line 6
14:04:20.941015 [ERR]    2688 VTeletextView - Line 7
14:04:20.942907 [ERR]    2688 VTeletextView - Line 8
14:04:20.945138 [ERR]    2688 VTeletextView - Line 9
14:04:20.948202 [ERR]    2688 VTeletextView - Line 10
14:04:20.951306 [ERR]    2688 VTeletextView - Line 11
14:04:20.954361 [ERR]    2688 VTeletextView - Line 12
14:04:20.957779 [ERR]    2688 VTeletextView - Line 13
14:04:20.961321 [ERR]    2688 VTeletextView - Line 14
14:04:20.965892 [ERR]    2688 VTeletextView - Line 15
14:04:20.970420 [ERR]    2688 VTeletextView - Line 16
14:04:20.975593 [ERR]    2688 VTeletextView - Line 17
14:04:20.981102 [ERR]    2688 VTeletextView - Line 18
14:04:20.988257 [ERR]    2688 VTeletextView - Line 19
14:04:21.014190 [ERR]    2688 VTeletextView - Line 20
14:04:21.041103 [ERR]    2688 VTeletextView - Line 21
14:04:21.048084 [ERR]    2688 VTeletextView - Line 22
14:04:21.055325 [ERR]    2688 VTeletextView - Line 23
14:04:21.062670 [ERR]    2688 VTeletextView - Line 24
14:04:21.062889 [ERR]    2688 VTeletextView - Start end
14:04:35.258549 [debug]  2688 VTeletextView - VTeletextView destruct
14:07:53.143572 [ERR]    2688 VTeletextView - Start draw
14:07:53.144214 [ERR]    2688 VTeletextView - Line 0
14:07:53.144542 [ERR]    2688 VTeletextView - Line 1
14:07:53.145051 [ERR]    2688 VTeletextView - Line 2
14:07:53.145722 [ERR]    2688 VTeletextView - Line 3
14:07:53.146547 [ERR]    2688 VTeletextView - Line 4
14:07:53.149978 [ERR]    2688 VTeletextView - Line 5
14:07:53.153192 [ERR]    2688 VTeletextView - Line 6
14:07:53.156852 [ERR]    2688 VTeletextView - Line 7
14:07:53.169069 [ERR]    2688 VTeletextView - Line 8
14:07:53.184688 [ERR]    2688 VTeletextView - Line 9
14:07:53.189244 [ERR]    2688 VTeletextView - Line 10
14:07:53.192761 [ERR]    2688 VTeletextView - Line 11
14:07:53.195987 [ERR]    2688 VTeletextView - Line 12
14:07:53.199765 [ERR]    2688 VTeletextView - Line 13
14:07:53.203887 [ERR]    2688 VTeletextView - Line 14
14:07:53.208296 [ERR]    2688 VTeletextView - Line 15
14:07:53.213758 [ERR]    2688 VTeletextView - Line 16
14:07:53.219578 [ERR]    2688 VTeletextView - Line 17
14:07:53.225740 [ERR]    2688 VTeletextView - Line 18
14:07:53.235873 [ERR]    2688 VTeletextView - Line 19
14:07:53.261731 [ERR]    2688 VTeletextView - Line 20
14:07:53.282297 [ERR]    2688 VTeletextView - Line 21
14:07:53.289233 [ERR]    2688 VTeletextView - Line 22
14:07:53.296425 [ERR]    2688 VTeletextView - Line 23
14:07:53.305019 [ERR]    2688 VTeletextView - Line 24
14:07:53.305455 [ERR]    2688 VTeletextView - Start end
14:07:57.611307 [debug]  2688 VTeletextView - VTeletextView destruct

GA-EP43 | headless | 1xCineS2 Dual | 1xSkystar 2.6D | VDR 1.7.37 
Frontend: 1xRasperry | 1xION3

MartenR

UINT TeletextDecoderVBIEBU::DeliverMediaSample(UCHAR* buffer, UINT *samplepos)
This function is the final function in the decoder, where the input from the demuxer arrives.

Also you can see in tfeed, what is happening. Also in Stream teletext can go through.

Marten

hondansx

#10
Quote from: MartenR on November 18, 2012, 14:16:31
UINT TeletextDecoderVBIEBU::DeliverMediaSample(UCHAR* buffer, UINT *samplepos)
This function is the final function in the decoder, where the input from the demuxer arrives.

Also you can see in tfeed, what is happening. Also in Stream teletext can go through.

Marten

I tried this before, but  this function and also tfeed will never be called.
I tried some log output in demuxerts but then on the client I got a black screen.

BTW: Can you fix the linebreaks in tfeed.cc
GA-EP43 | headless | 1xCineS2 Dual | 1xSkystar 2.6D | VDR 1.7.37 
Frontend: 1xRasperry | 1xION3

MartenR

QuoteBTW: Can you fix the linebreaks in tfeed.cc
No it is in some way not working on my computer... I tried it several times.

Quotetried this before, but  this function and also tfeed will never be called.
I tried some log output in demuxerts but then on the client I got a black screen.
You can look in demuxerts for the line
if (isteletextdecoded && pid == tID)
    {

if it enters this codeblock, teletext is coming.
I would advise you to check if the teletext pid is actually correct see at tables on the web, may be it changed and vdr has not updated your channel conf.

Marten

hondansx

#12
Tried several channels and if use the teletextplugin in vdr I see all teletext so this should not the problem.

if (isteletextdecoded && pid == tID) will never be reached, but before this line I will get this output.



      subActive = true;
    }   
    Log::getInstance()->log("DEMUXERTS", Log::DEBUG, "teletext pid %i tID %i", pid, tID);
    if (isteletextdecoded && pid == tID)
      Log::getInstance()->log("DEMUXERTS", Log::DEBUG, "isteletextdecoded %i pid %i", isteletextdecoded , pid);
    {   
      if (tActive)






18:21:12.685166 [debug]  150 DEMUXERTS - teletext pid 101 tID 104
18:21:12.688366 [debug]  150 DEMUXERTS - teletext pid 101 tID 104
18:21:12.757608 [debug]  150 DEMUXERTS - teletext pid 101 tID 104
18:21:12.758707 [debug]  150 DEMUXERTS - teletext pid 106 tID 104
18:21:12.762601 [debug]  150 DEMUXERTS - teletext pid 101 tID 104
18:21:12.957239 [debug]  150 DEMUXERTS - teletext pid 102 tID 104
18:21:12.959189 [debug]  150 DEMUXERTS - teletext pid 103 tID 104
18:21:12.977452 [debug]  150 DEMUXERTS - teletext pid 101 tID 104
18:21:12.980702 [debug]  150 DEMUXERTS - teletext pid 101 tID 104
18:21:12.985251 [debug]  150 DEMUXERTS - teletext pid 101 tID 104
18:21:12.993886 [debug]  150 DEMUXERTS - teletext pid 101 tID 104
18:21:12.996859 [debug]  150 DEMUXERTS - teletext pid 101 tID 104
18:21:13.060751 [debug]  150 DEMUXERTS - teletext pid 102 tID 104
18:21:13.064291 [debug]  150 DEMUXERTS - teletext pid 103 tID 104
18:21:13.074864 [debug]  150 DEMUXERTS - teletext pid 101 tID 104
18:21:13.075323 [debug]  150 DEMUXERTS - teletext pid 106 tID 104
18:21:13.078094 [debug]  150 DEMUXERTS - teletext pid 101 tID 104
18:21:13.080862 [debug]  150 DEMUXERTS - teletext pid 101 tID 104
18:21:13.163977 [debug]  150 DEMUXERTS - teletext pid 101 tID 104
18:21:13.179474 [debug]  150 DEMUXERTS - teletext pid 101 tID 104
18:21:13.183929 [debug]  150 DEMUXERTS - teletext pid 101 tID 104
18:21:13.184659 [debug]  150 DEMUXERTS - teletext pid 102 tID 104
18:21:13.185113 [debug]  150 DEMUXERTS - teletext pid 103 tID 104
18:21:13.440782 [debug]  150 DEMUXERTS - teletext pid 101 tID 104
18:21:13.461924 [debug]  150 DEMUXERTS - teletext pid 101 tID 104
18:21:13.465814 [debug]  150 DEMUXERTS - teletext pid 106 tID 104
18:21:13.475643 [debug]  150 DEMUXERTS - teletext pid 101 tID 104
18:21:13.480156 [debug]  150 DEMUXERTS - teletext pid 101 tID 104
18:21:13.486678 [debug]  150 DEMUXERTS - teletext pid 101 tID 104
18:21:13.487397 [debug]  150 DEMUXERTS - teletext pid 102 tID 104
18:21:13.487903 [debug]  150 DEMUXERTS - teletext pid 103 tID 104
18:21:13.490682 [debug]  150 DEMUXERTS - teletext pid 101 tID 104


Could it be the multidvb setup?
Could it be changes in vdr 1.7.25?


- Revised priority handling to allow receivers with a priority that is lower than
  that of live viewing (with suggestions from Frank Schmirler):
  + An idle device (one that is not used for live viewing and has no receiver
    attached to it) now has priority IDLEPRIORITY (-100).
  + An unused CAM slot now has priority IDLEPRIORITY.
  + The default priority of a cReceiver is now MINPRIORITY (-99).
  + A device that is used only for live viewing (no matter whether it's in Transfer
    Mode or real live mode) now has priority TRANSFERPRIORITY (-1).
  + The function cDevice::Receiving() now returns true if there is any receiver
    attached to the device. Its boolean parameter has no meaning any more.
  + The default value for the Priority parameter of the function cDevice::ProvidesChannel()
    has been changed to IDLEPRIORITY.
- Added a Query parameter to cDevice::GetDevice(), so that devices can be queried
  without side effects when zapping.
- Replaced min(max()) calls with the new function constrain().
- Fixed handling OSD color button texts in case a menu item has texts of its own
  (reported by Rolf Ahrenberg). If a plugin creates derived cMenuEditItems that set
  color button texts, these should not set the texts directly by calling
  cSkinDisplay::Current()->SetButtons(), but rather call the new member function
  cMenuEditItem::SetHelp().
- Moved the call to cStatus::MsgChannelSwitch(this, 0) to the beginning of
  cDevice::SetChannel(), so that any receivers that have been attached to the
  device by plugins may be detached before the final call to GetDevice().
  This actually reverts "Only calling cStatus::MsgChannelSwitch() if a channel
  is actually going to be switched or has actually been switched successfully"
  which was made in version 1.1.10, so please report if this has any unwanted
  side effects.


GA-EP43 | headless | 1xCineS2 Dual | 1xSkystar 2.6D | VDR 1.7.37 
Frontend: 1xRasperry | 1xION3

MartenR

Mmh, I am puzzled I know, what the problem is, but not why it is working in my setup. Probably since the etobi vdr contains some patches.
Anyway, you have to recognize that the teletext pid is never added to the receiver.
So we have to change this.
So please add to mvpreceiver at the server side the following code fragment to the constructor:

#if VDRVERSNUM >= 10712
AddPid(Channel->Tpid());
#endif

Test it, if it works, the next steps are:
Then generate a git patch, which we should send to Chris.

Marten

hondansx

#14
That did it.


--- mvpreceiver.c.orig 2012-11-18 19:52:35.231962571 +0100
+++ mvpreceiver.c 2012-11-18 19:52:48.348077659 +0100
@@ -51,6 +51,10 @@
   streamID = 0;
   tcp = NULL;

+#if VDRVERSNUM >= 10712
+  AddPid(channel->Tpid());
+#endif
+
   if (!processed.init(1000000)) return;
   pthread_mutex_init(&processedRingLock, NULL);


Now we have two patches on server side to send to chris. Should I do this or do you want this to do?
GA-EP43 | headless | 1xCineS2 Dual | 1xSkystar 2.6D | VDR 1.7.37 
Frontend: 1xRasperry | 1xION3