I would like to move this discussion to the developers list. G, for any follow ups we should drop the mvpmc-users e-mail address.
I am guessing, but I think we can get AC3 audio working if we can get the mythtv side of mvpmc to access the hardware like the ac3_spdif_play function in src/audio.c does. I am looking but I haven't found where mythtv is doing this... or maybe, it's not doing it right? I think I found the code in av_set_audio_output in file libs/libav/av.c, but my tweaking hasn't accomplished anything yet. stuart wrote: > Hi GC... > > Just wanted to report: I compiled Ozzy's patch and it appears to work. > I'll try switching to the more probable solution of calling the ulong > instead of the long function later. Jon, Simon, David and Eric appear > to be the authors of the effected file (libs/libcmyth/socket.c) - so > I'll let them decide on how to fix this - unless I hear otherwise. > > I also do not get sound on the MVPMC while watching Standard Definition > digitally recorded TV. Actually, I was very surprised MVPMC was able to > decode the video. I had thought digital TV was MPEG4 and that MVPMC is > only capable of doing MPEG2. Evidently, some digital TV or perhaps > Standard Definition programming is encoded as MPEG2. G, I think the > sound is AC3 and may not be... hey, wait a minute... we can set up the > MPVMC to pass through AC3 data... ...I'll try it... ...well that didn't > work. I wonder if the MVPMC / mythTV feature is using the same audio > code as the file browser (which I just tested w/an AC3 audio file - and > it worked). As I was saying, G, I think to get sound you will need to > transcode the AC3 to something MVPMC expects. > > I also tried an HDTV (720) recording and got nothing. Just a blank > screen. However, I was pleased that MVPMC did not crash. I was able to > back out of playing the recording and start another show. > > I understand some people have had success with symbolic links to their > HDTV files but renaming the links to <file_name>.dvx. Then, playing > them through VLC. I know, lots of hoops and a high pain level w.r.t. > ease of use - but it sounds like a way to view these digital files on > the MVPMC box. > > G C wrote: >> Sure enough, I found 3 entries in the 'recorded' table of my >> mythconverg database with chanid='4294967295'. They were generated by >> LiveTV on the new card. The title and program information were empty >> because I probably did not yet have program listings for the new >> tuner. So I blew away those three entries from my database and 3 >> corresponding empty mpeg files and now mvpmc shows my listings again. >> >> Although now I have a new problem. Recordings made on the new digital >> tuner do not play with sound on the mvpmc (either through MythTV or >> the filesystem). If I play the recordings on the native myth frontend >> or my Windows machine, they're fine. So I guess I'll be doing more >> troubleshooting tonight. >> >> On 1/10/07, G C <[EMAIL PROTECTED]> wrote: >>> I just spent a few minutes comparing the capture log I took against >>> the source code and the Myth protocol. It looks like it may not be >>> entirely a mvpmc problem. The Myth backend server appears to be >>> returning empty fields in this case. The MVPMC issues a >>> 'QUERY_RECORDINGS' command to get all the programs and their details. >>> The response from the myth server is documented in the protocol at >>> http://www.mythtv.org/wiki/index.php/Myth_Protocol_Command_QUERY_RECORDINGS >>> . In this case, all the fields are empty or some kind of NULL or >>> garbage value. It chokes on the 'chanid' (Channel ID) which is >>> returned from the myth server as 4294967295. >>> >>> So there are two problems here. >>> 1.) The myth server is returning no values for one of the entries. >>> Maybe I'll have to check my database for a corresponding garbage entry >>> and get rid of it. It may have been created when I was setting up the >>> new channels on tuner 2 for some reason. >>> 2.) MVPMC needs to handle situations like this better. Perhaps >>> ignore things like this? The regular Myth frontend seems to work and >>> it uses the same mechanism to get its data. So one would have to >>> assume that its ignoring this entry. >>> >>> >>> On 1/10/07, Ozzy Lash <[EMAIL PROTECTED]> wrote: >>>> It must not be the file size then, but according to Rick's log, it >>>> looks like the string "4294967295" is being received, and being passed >>>> to cmyth_rcv_long. Even though the comments in that function indicate >>>> that it can handle a 64bit number, the code only handles a 32bit >>>> signed int. I am wondering if something on the mythtv side is sending >>>> an unsigned long instead of a long and is trying to send -1. >>>> >>>> You could try the attached patch (I did it quick with no testing) and >>>> see what happens. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Mvpmc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mvpmc-users mvpmc wiki: http://mvpmc.wikispaces.com/
