Messages

Hi Chris,

this was a regression of my previous upload. Fixed in trunk.
Please try again.
But Gnome I fear still wont work.
I assume some environmental things, like QTDIR, etc.

Hi Chris,

thanks for testing.

This all look strange to me and before I now go into wild guesses, I think it's time to play with some other installations on my own.

Crashing: I also see this frequency of crash, but in my case most of the time it locks up the MVP entirely which means it's a crash in the kernel drivers or hardware. I see this as a fault in a layer that is out of our control.. Now maybe there is something vomp is doing which the hardware doesn't like, or maybe there would be a change to vomp possible that would prevent it, but with the MVP locking up entirely it's very difficult to debug.

Ja, sorry, hangup/freeze is precise.
One pattern I've seen so far, was that shortly before it freezes, the MVP gets a bit unresponsive to the remote key presses. So the last 2 key presses were delay by 0.5 or 1s, but most time (due to the unpatiency) I anyway pressed too many times, so it freezes shortly afterwards.
Looks hard to debug, if you say the box is hanging...

TCP window size: What type of MVP was this with?

The one in the living room is a E1 - this one is where it is for sure most used one and therefore I've seen it quite often.
But I roughly remember similar with a D3A which is more seldomly used (sleeping room).

Hello,

a) crashes:
I have seldom (~ once a week) crashes with current dongle.
It only happens when playing recordings and pressing intensively 10s and/or 60s foreward or backwards.
I know a log is mandatory, but as it is so seldom, I don't have enabled it yet. Will do when I come to it.

b) Tcp package size:
Currently default tcp package size is 2048. I had for some channels with high bitrates a lot of times stuttering in the tone. Regardless if it was live-tv or if it was playing from recording from a high bitrate channel.
Now that I changed the tcp package size to 4096, these hickups are gone (at least much much more seldom).
As I now assume, the hickups came from network concurrency, would it make sense to increase this default package size to at least 4096?

Just a new screenshot of the channel selection with EPG entries.

As I reimplemented so far everything with Qt, I would like to state following "unusual" things (unusual means I had problems doing it the right way when I tried to implement it):

- Strings: Strings are not defined by length (in Qt strings begin with a length information). The length is identified by the trailing /0, so you need to parse the package till you find a /0. Strings are not Utf-8, they are latin or something similar - so each byte one characted (maybe someone else can define it clearly).

- Mediaprotocol: The mediaprotocol has another length information for their content. I see this as redundant, as the package already has a length information for custom data.

- Mediaprotocol in general: I assume with the new version (not yet adjusted to 0.3.0), which allows pictures and sound in parallel the protocol will change here again. Current protocol won't allow sound and picture in parallel (only one media file can be opened at the same time).

- Request/Response: If possible, I would change the protocol here a bit. I would always start with a length information. But this is e.g. not existing for keepAlive packages (they have length=8). So you always need to parse the package what type it is, and depending on the type you get the length at a different position and based on the length you then can evaluate if the full package already arrived at the socket or not (not means for me waiting for next package arriving).

- Keep alives: You need to send regularely keep alive packages, as long as you didn't send any request/response package within, hmm I think it was 10s. Just do it every 5s and you are fine. "Streaming" recordings or media files involves request/response packages, no keepAlive necessary. Only live-tv streaming needs keep alives.

>Maybe someone can fill in some details and add some notes reagarding how to access Live TV and recordings

Live-TV: You send the request package, which channel is to be streamed and then the server starts already streaming packages until you send the request package stopstreaming. The client now need to handle the packages, there is no exchange of request for the streamdata in between server/client.
As there is no exchange (request/response) you need to send keepAlives during streaming to keep the connection alive.
Do you need more info/details on that?


Recordings:
Recordings and Mediadata are very very similar - as both are just a request for a file transfers (they completely share the same protocol-only the "open" is different, the read is equal).

Basically it comes down to the point that you send a request package, which file you want to be transferred.

Then you just send request packages in order to get junks of data (pos, length). You don't need to stop here anything, just don't ask for more data and you are done. If you want a different file, just request to open the diifferent file.

Compare the request for these "files" with something like fileLength=fileOpen("path/filename") and the request for data with data=read(pos, length) where pos <  fileLength. pos > fileLength will cancel the connection, pos + length > fileLength is fine.

> but what is the type of the streamed data
Just the plain mpeg data (I assume) as it is coming from the DVB card. No encapsulation or whatever is done here. I just pass these data to Phonon alias Xine and it works.

If you have more questions, just let me know.

Nobody is answering yet, so I will give it a try:
- The black screen is on MVP or Windowsclient or on both?
- In case MVP, what does the log spit out when you enable logoutput?
- What are the settings for the PVR card? Does it give e.g. PAL in normal resolution or something different? Maybe if it is not the same format then the internal decoders get issues...

I'm also unsure, but what google told me about "is not a member of" shows a lot of time mixed systems.
May it be possible that you have a Qt version <4.4 somewhere on your system? Phonon was introduced in Qt4.4.

___________
Update:
I'm rather sure you have something like Qt 4.4 and KDE 4.0 installed (or some similar old stuff lying around).
In between KDE 4.0 and Qt 4.4 the Phonon library was "moved" from KDE to Qt, or at least it is a new version.

It seems you now try to compile the Qt 4.4 phonon library with libraries/hearders from KDE 4.0, so newer Qt with older KDE.

This may explain the error message that the "MediaPlay" is not a member of QStyle.

Firstly, when I run it, it broadcasts for the server, but doesn't acknowledge any responses. IPTraf shows that responses are returning from the VDR server.

Are you running it on the same machine as a vdr instance is running? In this case, I know I had issues as the port was occupied, but didn't try to solve it (yet).
Otherwise I changed the way the server is search 3 weeks ago, made a short test and thought it is working (which may not be the general case).

Vomp clients may run on the same host as VDR server with the following Vomp server patch for udpreplier.c
      ds.send(ds.getFromIPA(),ds.getFromPort(), serverName, strlen(serverName));
instead of:
      ds.send(ds.getFromIPA(),3024, serverName, strlen(serverName));

The patch returns response to the source UDP address of the request for Vomp servers instead of always using 3024.

Untested, but out of Qt Docu:
In vdrfindserver.cpp line 27
instead of
    m_udpSocket->bind( 3024 );
using
    m_udpSocket->bind( 3024, QUdpSocket::ShareAddress | QUdpSocket::ReuseAddressHint );

May also do the trick.
Is it then working? (I can only check when I'm back at home)

Firstly, when I run it, it broadcasts for the server, but doesn't acknowledge any responses. IPTraf shows that responses are returning from the VDR server.

Are you running it on the same machine as a vdr instance is running? In this case, I know I had issues as the port was occupied, but didn't try to solve it (yet).
Otherwise I changed the way the server is search 3 weeks ago, made a short test and thought it is working (which may not be the general case).

Anyway, supplying the -s switch with my server address makes it connect. It gets the channel list and recordings lists fine,

Good: In case you provide images in the ../bin/images/logos/ dir from http://www.mcnutt.org/duncan/vdr/ you also get nice looking channel logos :-)

however, on starting a live channel or recording I get the message:

Code Select Expand

WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded

I have the debian package phonon-backend-xine installed with debian version number: 4:4.1.0-2.

Do you run KDE 4.1 completely or just qt and phonon packages?
I can remember that the qt + phonon were missing something from normal KDE 4.1 packages. I need to recheck then again what exactly when I'm at home.
In case KDE4.1 is installed: Are you able to run the files with Dragonplayer?
In case w/o KDE4.1: Then you should at least be able to play sound with gstreamer-backend defined/installed. Does this work?

________________________

Update: I think the relevant packages were kde4libs, kdebase-runtime.
maybe also kdebase-workspace, but I fear this removes kde3 then.
So the basic environment to run KDE 4 programs.

Reason:
phonon-xine uses still some very minor functionality of kde4. These will be / are currently removed for next release of Phonon (which maybe KDE 4.2 or Qt 4.5, whichever comes first).

Update:
Live-TV, playing recordings and music files works now correctly and stable - you definetly can use it now already for comfortably watching live-tv.
Switching channels and going fullscreen is now supported too.

I consider this functionality stable and ready for alpha release.
Also the code doesn't have any hack anymore, so it is a clear basis for further development. Rough edges are still there, but only the beauty of the code is the issue.

What's still missing till a first alpha release is (in my opinion):

• OSD support
• EPG info in OSD and channel list

These are the functionality that I consider necessary for a broader testing. Implementing this functionality will just take some weeks from now on.

To be implemented after the fist alpha is:

• fancy design, beautiness, high WAF, ...
• EPG form
• Timers (setting/deleting)
• moving/deliting recordings
• storing configuration
• i18n

Bad news:
No platform is supported beside of Linux with Phonon-xine-backend.

Neither MacOs (papaBlues was so kind to test it with quicktime-backend w/o success) nor Windows (my tests with DS9-backend) didn't work so far for video. Audio files are working on all backends.
I still have hope for Windows with DS9, as I'm sure same issues with selecting the right graph applies here like with the current Windows client
Also for all platforms we may get results with the not yet released MPlayer and/or VLC backends.

But for the first alpha I now plan for Linux-xine-backend alone.

If you have any question or suggestion, just let me know.
You can get the code from the project homepage - see my previous post.

Philipp

Update to the current status.

This patch is not included in 0.3.0 and I currently don't have an updated patch.
This is not because of the normal time constrains or technical reasons, it is just that I'm unsure how we should do scrolling in the 0.3.0, i.e. when using the old remote in Live-TV mode.

We do have following situations in 0.3.0 (all the old remote) for showing the programme summary:
Play Recording:
    - "red" shows the static programme summary
    - "up" and "down" could still be used for scrolling in programme summary
Recordings list:
    - Menu entry "Summary" shows static programme summary
    - "up" and "down" could still be used for scrolling in programme summary
Live-TV:
    - "up" and "down" switches the channel up and down
    - "red" shows the static programme summary
    - when pressing "ok", "up" and "down" let's you scroll through the EPG entries

As you can see, Live-TV is my issue, as there is for me no way to scroll up and down usability vise in a clear way and consistent with the other 2 options.

If you have any clue what we may do, please let me know.
Suggestions and proposals are very much welcome.

Sorry I don't have a suggestion for this.
Guess I'm pretty happy with 0.2.7.6.1. and was hoping the functionality could/would remain as the core software was improved.

I will update the original post of the patch with current status, so any suggestions/proposal please then put in the right thread. Here it would be OT.

scrolling summary for long EPG entries from XMLTV
Is that right?

I didn't update my patch for the scrolling of EPG programme summary. So confirmed it cannot be included.
My biggest issue is rather that I have no clue how to do scrolling now in Live-TV with the old remote. There is just no button left...
Any ideas?

Sooner or later the QtVomp will have subtitle support.

As this is supported by Phonon-VLC-MPlayer - at least the webpage for this phonon plugin states it is supported - it will be in QtVomp as well.
And this plugin is available for Linux/Windows/Mac and WinCE.

Untested for sure, but good hope.

Sadly: Currently not on my priolist and/or it needs a not yet released VLC version out of daily snapshots. So a bit a hassle to set up.