Messages

Hi,

I use the analog output and at the beginning of every channel or recording I am getting sizzles for 0.5 s, which is annoying.
It looks like, this is an rasp problem. Is there any possibility to add some mute or delay in audioomx, so this sizzles/distortion are suppressed or not audible.

.

I have updated the l10n Directory and now the menu umlauts are okay on my rasperry (and on my mvp too)
So I can leave my vdr in iso.;-)

Thanks, I will give it a try.

Hey Guys thanks for the input.

I will give a try

How can I add an unused key of my tv-remote.
Log says

Code Select Expand


21:43:33.253613 [debug]  5082 Remote - CECLOG: 83303 8 >> 01:42:03
21:43:33.253796 [debug]  5082 Remote - CECLOG: 83303 4 >> TV (0) -> Recorder 1 (1): deck control (42)
21:43:33.754886 [debug]  5082 Remote - CECLOG: 83804 16 received data: header:00030002 p0:00034201 p1:00000000 p2:00000000 p3:00000000 reason:2
21:43:33.756134 [debug]  5082 Remote - CECLOG: 83805 8 >> 01:42:03
21:43:33.756358 [debug]  5082 Remote - CECLOG: 83805 4 >> TV (0) -> Recorder 1 (1): deck control (42)
21:43:53.898613 [debug]  5082 Remote - CECLOG: 103948 16 received data: header:00030010 p0:00918A01 p1:00000000 p2:00000000 p3:00000000 reason:10


What is the right way now that all german umlauts are shown right on the rasperry?

1. vdr env should be utf-8?
2. l10n/main-de should be utf-8?
3. rasp-vompclient env should be utf-8?

Any hints would be great, because on rasp-client side all umlauts are broken for me.

Change the value and hit back, vomp segfaults.

Code Select Expand


Program terminated with signal 11, Segmentation fault.
#0  0x00073f20 in VOpts::doSave (this=0x83e480) at vopts.cc:445
445         Osd::getInstance()->setFont(options[i]->optionkeys[options[i]->userSetChoice]);


Ok, send it to chris.

Priority changes within vomp/vdr is working now, but I have to test further, if it solves the channel not available problem. Maybe this are other changes within vdr.
I give back feedback later about this.

In osdopenvg, you can just change the

Code Select Expand

float font_size=16.f;
but it is very likely the arrangement of the elements of UI is then not optimal.

Ok that helped me a lot with higher font size, but now I have to adjust the window for the epg title entry in live tv mode. Where can I change this?

That did it.

Code Select Expand


--- 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?

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.

Code Select Expand



      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)




Code Select Expand


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?

Code Select Expand


- 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.




Code Select Expand

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

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.

Code Select Expand


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:

Code Select Expand


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


Problem is that if a timer is starting vompclient gets a channel not available message. Not a real  problem but should be fixed.

The question is how.
I mean a timer should have priority over the vompclient. You do not wish, that zapping kills your recordings right??

That's surely true, but I should mentioned, that it should not happen in a multidbvcard environment, where resources are free and vdr will know about this.

I mean it was always like this at my home, that a timer kicks out someone who watches a recording?

Not with more than one dbv card. ;-)

EDIT: (Do you mean since the default is 0?)

Yes

EDIT2: I have check this, you probably only what that the sanity checks are modified so that negative values are accept. This should be easy, but I am running an old vdr version I need someone to test it.

Maybe its time to update to a newer version of your vdr. ;-) I can test it. Thanks about this