mvpmc-tracker Mailing List for MediaMVP Media Center
Status: Alpha
Brought to you by:
gettler
You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(12) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: SourceForge.net <no...@so...> - 2010-11-18 18:54:07
|
Bugs item #2366810, was opened at 2008-11-30 15:06 Message generated for change (Comment added) made by visierl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2366810&group_id=103474 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: build Group: 0.3.4 Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Graham Jones (jones139) Assigned to: Nobody/Anonymous (nobody) Summary: Toolchain build fails Initial Comment: Running make mvp following a download of mvpmc-0.3.4 fails with an error - no ppc405 cross compiler is installed so it should have built one itself, but the error is relating to the cross compiler gcc etc. not existing. Looking back through the log it appears that the download of the linux-libc-headers-2.4.25.tar.bz2 failed, but the build script did not stop at this point, but tried to carry on. The problem appears to be that the required file has moved location on the server to http://www.uclibc.org/downloads/old-releases/toolchain/linux-libc-headers-2.4.25.tar.bz2. - the build script was not looking in "old-releases". Downloading it manually and putting it in ~/downloads appears to have allowed the build to progress (but it is not finished yet....). For info I am using Ubuntu 8.10 (intrepid), but I do not think this is a host distribution issue. GJ ---------------------------------------------------------------------- >Comment By: Eric Lund (visierl) Date: 2010-11-18 12:54 Message: This appears to have been fixed, but I can't find exactly where. In any case, the offending tarball is now being downloaded from: http://www.uclibc.org/downloads/old-releases/toolchain/linux-libc-headers-2.4.31.tar.bz2 more or less as suggested by the bug description. Probably the problem was fixed implicitly when moving from 2.4.25 to 2.4.31. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2366810&group_id=103474 |
From: SourceForge.net <no...@so...> - 2008-12-10 11:06:00
|
Bugs item #2407746, was opened at 2008-12-08 22:29 Message generated for change (Comment added) made by shyde You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2407746&group_id=103474 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Mogens Lauridsen (mlla) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong array size in src/mythtv.c Initial Comment: In src/mythtv.c line 4267-4272 my compiler complains about this code: if (strlen(sqlprog[which].description) > 384) { sqlprog[which].description[381]='.'; sqlprog[which].description[382]='.'; sqlprog[which].description[383]='.'; sqlprog[which].description[384]='\0'; } sqlprog is of the the cmyth_program_t type, where the description field is defined as: (include/cmyth.h) char description[280]; ---------------------------------------------------------------------- >Comment By: Simon Hyde (shyde) Date: 2008-12-10 11:05 Message: I believe I've already resolved this in the git repo. Please re-file if you believe this problem still exists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2407746&group_id=103474 |
From: SourceForge.net <no...@so...> - 2008-12-10 11:01:07
|
Bugs item #2407564, was opened at 2008-12-08 21:06 Message generated for change (Settings changed) made by shyde You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2407564&group_id=103474 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Mogens Lauridsen (mlla) Assigned to: Nobody/Anonymous (nobody) Summary: Memory overwrite in src/wss.c Initial Comment: The char array wss_ntsc_bits has a size of 17. However there are a couple of out of bounds write in the function wss_ntsc_update_surface: Line 274: memset(&(wss_ntsc_bits[16]),1,6); And line 289-292: for(i = 0; i < 6;i++) { wss_ntsc_bits[16+i] = (reg&(1<<i))?1:0; } ---------------------------------------------------------------------- >Comment By: Simon Hyde (shyde) Date: 2008-12-10 11:01 Message: I believe I've already fixed this in the latest git. Please pull the latest code from the git repo, and re-file if the problem still exists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2407564&group_id=103474 |
From: SourceForge.net <no...@so...> - 2008-12-10 10:59:22
|
Bugs item #2407506, was opened at 2008-12-08 20:41 Message generated for change (Settings changed) made by shyde You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2407506&group_id=103474 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: build Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Mogens Lauridsen (mlla) Assigned to: Nobody/Anonymous (nobody) Summary: Compiler errors in src/tvguide.c: Array out of bounds. Initial Comment: In line 315: rtrn->chanstr[149] = '\0'; This is out of bounds, and I think it should be: rtrn->title[149] = '\0'; Patch is attached. ---------------------------------------------------------------------- >Comment By: Simon Hyde (shyde) Date: 2008-12-10 10:59 Message: I believe I fixed this in commit 438725012c6ee7f768f880eff12e4c95790d758d, pushed to the main repo 7 days ago. Try the latest version from git, and re-file your bug if it won't build. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2407506&group_id=103474 |
From: SourceForge.net <no...@so...> - 2008-12-08 22:30:03
|
Bugs item #2407746, was opened at 2008-12-08 23:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2407746&group_id=103474 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mogens Lauridsen (mlla) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong array size in src/mythtv.c Initial Comment: In src/mythtv.c line 4267-4272 my compiler complains about this code: if (strlen(sqlprog[which].description) > 384) { sqlprog[which].description[381]='.'; sqlprog[which].description[382]='.'; sqlprog[which].description[383]='.'; sqlprog[which].description[384]='\0'; } sqlprog is of the the cmyth_program_t type, where the description field is defined as: (include/cmyth.h) char description[280]; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2407746&group_id=103474 |
From: SourceForge.net <no...@so...> - 2008-12-08 21:06:09
|
Bugs item #2407564, was opened at 2008-12-08 22:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2407564&group_id=103474 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mogens Lauridsen (mlla) Assigned to: Nobody/Anonymous (nobody) Summary: Memory overwrite in src/wss.c Initial Comment: The char array wss_ntsc_bits has a size of 17. However there are a couple of out of bounds write in the function wss_ntsc_update_surface: Line 274: memset(&(wss_ntsc_bits[16]),1,6); And line 289-292: for(i = 0; i < 6;i++) { wss_ntsc_bits[16+i] = (reg&(1<<i))?1:0; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2407564&group_id=103474 |
From: SourceForge.net <no...@so...> - 2008-12-08 20:41:35
|
Bugs item #2407506, was opened at 2008-12-08 21:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2407506&group_id=103474 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mogens Lauridsen (mlla) Assigned to: Nobody/Anonymous (nobody) Summary: Compiler errors in src/tvguide.c: Array out of bounds. Initial Comment: In line 315: rtrn->chanstr[149] = '\0'; This is out of bounds, and I think it should be: rtrn->title[149] = '\0'; Patch is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2407506&group_id=103474 |
From: SourceForge.net <no...@so...> - 2008-11-30 21:06:37
|
Bugs item #2366810, was opened at 2008-11-30 21:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2366810&group_id=103474 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: build Group: 0.3.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Graham Jones (jones139) Assigned to: Nobody/Anonymous (nobody) Summary: Toolchain build fails Initial Comment: Running make mvp following a download of mvpmc-0.3.4 fails with an error - no ppc405 cross compiler is installed so it should have built one itself, but the error is relating to the cross compiler gcc etc. not existing. Looking back through the log it appears that the download of the linux-libc-headers-2.4.25.tar.bz2 failed, but the build script did not stop at this point, but tried to carry on. The problem appears to be that the required file has moved location on the server to http://www.uclibc.org/downloads/old-releases/toolchain/linux-libc-headers-2.4.25.tar.bz2. - the build script was not looking in "old-releases". Downloading it manually and putting it in ~/downloads appears to have allowed the build to progress (but it is not finished yet....). For info I am using Ubuntu 8.10 (intrepid), but I do not think this is a host distribution issue. GJ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2366810&group_id=103474 |
From: SourceForge.net <no...@so...> - 2008-07-30 18:56:49
|
Bugs item #2032565, was opened at 2008-07-30 11:33 Message generated for change (Comment added) made by shyde You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2032565&group_id=103474 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: mvpmc - video player Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Time elapsed in mythtv OSD is nonsensical Initial Comment: To reproduce: play any recording with the mythtv client, and bring up the OSD with "OK". The time elapsed shows huge values, e.g. over 19 hours into a recording that is less than an hour long. I can reproduce this reliably on every recording I have, on versions of code up to & include 20080722 (haven't tried anything newer, but aren't any related updates in the git repository since then). ---------------------------------------------------------------------- >Comment By: Simon Hyde (shyde) Date: 2008-07-30 19:56 Message: Logged In: YES user_id=2082933 Originator: NO This isn't actually a problem with the mythtv client. The "elapsed time" is actually drawn from the current video STC/PTS timestamp. This works fine for files which have been encoded with that length, however it doesn't work at all for broadcast MPEG streams (ie DVB/ATSC). For these the value just keeps on going up through the day, until they reach the maximum value, then roll back around again. Recordings of these broadcast streams will therefore start at a strange value. Maybe the video player could pick up the PTS at the start of a file and subtract that from the value it uses for display... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2032565&group_id=103474 |
From: SourceForge.net <no...@so...> - 2008-07-30 10:33:15
|
Bugs item #2032565, was opened at 2008-07-30 10:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2032565&group_id=103474 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mvpmc - mythtv Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Time elapsed in mythtv OSD is nonsensical Initial Comment: To reproduce: play any recording with the mythtv client, and bring up the OSD with "OK". The time elapsed shows huge values, e.g. over 19 hours into a recording that is less than an hour long. I can reproduce this reliably on every recording I have, on versions of code up to & include 20080722 (haven't tried anything newer, but aren't any related updates in the git repository since then). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2032565&group_id=103474 |
From: SourceForge.net <no...@so...> - 2008-07-18 17:20:52
|
Bugs item #2021670, was opened at 2008-07-18 17:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2021670&group_id=103474 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mvpmc - vlc transcoding Group: 0.3.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: playing a file via vlc results in child failed error 11 Initial Comment: While playing files via vlc I experience a restart of the mvpmc-process after 10-60 seconds. Output of mvpmc 0.3.4 over telnet: video write thread running audio write thread running http opened /mnt/movies/WECHSEL500-2/SERIES/Die Dinos (tt0101081)/s01/Die.Dinos.-.S01E03.-.Der.Schleudertag.by.Waschtel.avi Freeing PAT Decoder Initializing PAT Decoder write threads released Freeing PAT Decoder Initializing PAT Decoder VLC: broadcast messages enabled == 0 VLC: VLC_PCTPOS Position: 14%, Time: 188020000.000000, Length: 1320000000.000000 auto detection transport stream returned 1 Lost Sync libdvbpsi error (PSI decoder): TS discontinuity (received 1, expected 0) for PID 0 Decoding Program Association Table prog 1 pmtpid 66 Freeing PMT Decoder Initializing PMT Decoder libdvbpsi error (PSI decoder): TS discontinuity (received 1, expected 0) for PID 66 Decoding Program Map Table pcr_pid = 69 Elementary Stream type 3 has pid 68 Audio Type = unknown ffffffff Allocating ipack 0 to pid 68; forcing streamid to 0xc0 Elementary Stream type 2 has pid 69 Allocating ipack 1 to pid 69; forcing streamid to 0xe0 found 1 video streams; 1 audio streams; 0 subtitle streams switch to MPEG audio output device Changing to aspect 3, afd -1 Source video aspect ratio: 16:9 Setting WSS aspect to: 7 Source video aspect ratio: 16:9 Setting WSS aspect to: 7 Changing to aspect 3, afd -1 Source video aspect ratio: 16:9 Setting WSS aspect to: 7 Changing to aspect 3, afd -1 Source video aspect ratio: 16:9 Setting WSS aspect to: 7 ** here was the crash ** child failed, with status 11, restarting... child pid 284 MediaMVP Media Center Version 0.3.4 fnt_createfont: using font /etc/helvR10.fnt fnt_createfont: /etc/helvB18.pcf,0 not found glyph_count = 756 (2f4) def char 0 (0) size 8960 byte1 0,34 byte2 0,255 pcf_createfont: using font /etc/helvB18.pcf Sun Nov 18 11:20:12 EST 2007PAL mode, 720x576 createfont: (height == 0) found builtin font System (0) createfont: (height == 0) found builtin font System (0) screen is 720 x 576 etc. dth <des...@go...> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2021670&group_id=103474 |
From: SourceForge.net <no...@so...> - 2008-07-17 19:35:37
|
Bugs item #2020907, was opened at 2008-07-17 19:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2020907&group_id=103474 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 0.3.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: John (gardez) Assigned to: Nobody/Anonymous (nobody) Summary: "make host" fails on 64-bit linux Initial Comment: There seem to be a number of integer->pointer and pointer->integer conversions that assume 32-bit address space. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2020907&group_id=103474 |
From: SourceForge.net <no...@so...> - 2008-07-02 11:35:08
|
Feature Requests item #2008715, was opened at 2008-07-02 12:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634923&aid=2008715&group_id=103474 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Simon Hyde (shyde) Assigned to: Nobody/Anonymous (nobody) Summary: Internationisation/Localisation Initial Comment: mvpmc is currently full of hard-coded strings in US English, and I suspect there are some assumptions about date formats in there somewhere too. It ought to be using gettext to allow menus/interface to be translated, and make sure that it uses localisation-compatible date formatting functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634923&aid=2008715&group_id=103474 |
From: SourceForge.net <no...@so...> - 2008-07-02 10:45:18
|
Feature Requests item #2008674, was opened at 2008-07-02 11:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634923&aid=2008674&group_id=103474 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Simon Hyde (shyde) Assigned to: Simon Hyde (shyde) Summary: Re-Write TV Guide Initial Comment: The TV Guide needs re-writing for a number of reasons: 1. The current code assumes that all programs either start on the hour, or 30 minutes past it, and have a duration in multiples of 30 minutes. This makes it worse than useless outside North America, where it's common to have show durations and start times which don't fit this pattern. 2. It's put GUI code into libcmyth. There shouldn't be any GUI code in libcmyth. 3. It doesn't conform to the viewport. 4. The TV Guide is hard-coded to be very MythTV specific, this prevents it from ever being extended to work with (for example) VDR. I have started work on this re-write, but haven't done anything on it for a month or so. My current WIP (which has a working guide, but none of the hooks in/out of it) can be found at: http://www.mvpmc.org/~shyde/repos/tvguide_rewrite.git/ Simon ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634923&aid=2008674&group_id=103474 |
From: SourceForge.net <no...@so...> - 2008-07-02 10:35:42
|
Feature Requests item #2008667, was opened at 2008-07-02 11:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634923&aid=2008667&group_id=103474 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Private: No Submitted By: Simon Hyde (shyde) Assigned to: Nobody/Anonymous (nobody) Summary: Handle EOF more sensibly on (growing) video files. Initial Comment: mvpmc can play back video files which are still growing as they are recorded/copied/.... However when the video player's file I/O routines reach the end of a file mvpmc seems to stop trying to read from the file and allow its buffers to run dry. After reaching an EOF, it ought to be possible to re-try attempts to read data until more is appended on the end of a file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634923&aid=2008667&group_id=103474 |
From: SourceForge.net <no...@so...> - 2008-07-02 10:30:40
|
Feature Requests item #2008662, was opened at 2008-07-02 11:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634923&aid=2008662&group_id=103474 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mvpmc - video player Group: None Status: Open Priority: 5 Private: No Submitted By: Simon Hyde (shyde) Assigned to: Nobody/Anonymous (nobody) Summary: Prevent seek beyond end/start of videos Initial Comment: Currently you can easily make the mvpmc seek beyond the start/past the end of a video file, leaving you with a blank screen. The mvpmc ought to stop you from doing this, always placing you at the start of the file, or (say) 5 seconds from the end depending on which direction your seeking in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634923&aid=2008662&group_id=103474 |
From: SourceForge.net <no...@so...> - 2008-07-02 10:11:46
|
Bugs item #2008649, was opened at 2008-07-02 11:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2008649&group_id=103474 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Simon Hyde (shyde) Assigned to: Nobody/Anonymous (nobody) Summary: Seek by number of seconds is seriously flawed Initial Comment: There are a number of flaws/bugs/problems in the seek by seconds functionality (triggered when the user hits the Seek Back/Forward/Rewind buttons) which cause it not to work very well: 1. It suffers from the same buffering issues described in #1990985 2. After the initial seek it then attempts to make sure it has actually jumped by the right number of seconds, but this code is also flawed in a number of ways: a) Current and target times are converted from 90kHz clock value to a H:M:S values before being compared, somewhere along the line this seems to get messed up, and comparisons don't seem to work. This whole conversion stage is unnecessary, and it would seem to be easier to just compare the 32 least significant bits of the original (33-bit) value. b) If it determins it needs to seek back/forwards from here it then performs a seek() directly on the file, but doesn't perform the necessary operations to put the demuxer back into a "seeking" mode, this could well screw up lip sync, aswell as a bunch of other things. Simon ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=2008649&group_id=103474 |
From: SourceForge.net <no...@so...> - 2008-07-01 18:26:47
|
Feature Requests item #2008027, was opened at 2008-07-01 12:01 Message generated for change (Comment added) made by visierl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634923&aid=2008027&group_id=103474 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mvpmc - mclient Group: No Release Target Status: Open Priority: 5 Private: No Submitted By: Rick Stuart (stuart) Assigned to: Rick Stuart (stuart) Summary: FLAC support in mclient Initial Comment: There have been requests for Free Lossless Audio Compression support in mclient. Some people prefer to rip their CDs using FLAC as it preserves the original data. In general, the resulting file size is smaller then the original recording but not as small as a loss-full MP3 files (which are usually 1/10 the size of the original file). Technically, mclient should be able to support FLAC. However, the implementation turns out to be complex. Unless SqueezeCenter believes the client will support FLAC, it will not pass FLAC data to it. Rather it will transcode the file to a format it believes the client can handle. Currently, mclient communicates to SqueezeCenter using UDP. This format is used in older versions of SqueezeCenter clients which do not support FLAC. So, the first step mcilent needs to make towards supporting FLAC is to switch from UDP to TCP when communicating to the SqueezeCenter server. With this change comes a new set of commands which could require new logic in mclient (i.e. possibly new ways to control the local audio buffer & new types of display data which need to be filtered out). So just to get mclient back to where we currently are requires a moderate to large amount of work. ---------------------------------------------------------------------- Comment By: Eric Lund (visierl) Date: 2008-07-01 13:26 Message: Logged In: YES user_id=988828 Originator: NO What makes TCP necessary to support FLAC? It is not obvious from your description why TCP would be necessary. Does SqueezeCenter not believe your client supports FLAC if the Transport Layer is UDP? Something about using an unreliable transport protocol for lossless compression? That seems like an invalid heuristic to me... Could you explain that further? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634923&aid=2008027&group_id=103474 |
From: SourceForge.net <no...@so...> - 2008-07-01 17:31:50
|
Feature Requests item #1572549, was opened at 2006-10-07 05:01 Message generated for change (Comment added) made by stuart You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634923&aid=1572549&group_id=103474 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mvpmc Group: None Status: Open Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Better mp3 player/browser Initial Comment: While slimserver is a fine example of a mp3 player/browser... it's woefully lacking when you try to access a really large mp3 collection... say 20,000 or more. It becomes cumbersome and quite lacking... What feature I request is, how about some better, like perhaps GNUMP3D? While GNUMP3D is written in perl and quite feature loaded... I can't imagine why it couldn;t be written in C and stripped down to a much leaner feature set. It's a much simpler player than slimserver, but highly useable none the less. Jerry ---------------------------------------------------------------------- Comment By: Rick Stuart (stuart) Date: 2008-07-01 17:31 Message: Logged In: YES user_id=14406 Originator: NO Hi Jerry, I don't know if you are still monitoring this tracker ticket. A few thoughts: I haven't see anyone pick up on this, SqueezeCenter (aka SlimServer) does just about everything I want, and, currently, there is little room for new features in the mvpmc project (i.e. the target's memory is almost full). There is a plug in effort (only loads the application currently running) under way. However, I think that will probably be implemented on a different media extender box (the NMT box) first. I do have some questions: Is GNUMP3D a server which supports "thin" clients? If not, and you were thinking of running GNUMP3D on the mvpmc box, I can honestly say I doubt you will find there are enough resources to handle the amount of data let alone the application. With all that background information, if you want to code up this feature (start translating it from PERL to C) I might be able to help out if you have any questions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634923&aid=1572549&group_id=103474 |
From: SourceForge.net <no...@so...> - 2008-07-01 17:01:16
|
Feature Requests item #2008027, was opened at 2008-07-01 17:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634923&aid=2008027&group_id=103474 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mvpmc - mclient Group: No Release Target Status: Open Priority: 5 Private: No Submitted By: Rick Stuart (stuart) Assigned to: Rick Stuart (stuart) Summary: FLAC support in mclient Initial Comment: There have been requests for Free Lossless Audio Compression support in mclient. Some people prefer to rip their CDs using FLAC as it preserves the original data. In general, the resulting file size is smaller then the original recording but not as small as a loss-full MP3 files (which are usually 1/10 the size of the original file). Technically, mclient should be able to support FLAC. However, the implementation turns out to be complex. Unless SqueezeCenter believes the client will support FLAC, it will not pass FLAC data to it. Rather it will transcode the file to a format it believes the client can handle. Currently, mclient communicates to SqueezeCenter using UDP. This format is used in older versions of SqueezeCenter clients which do not support FLAC. So, the first step mcilent needs to make towards supporting FLAC is to switch from UDP to TCP when communicating to the SqueezeCenter server. With this change comes a new set of commands which could require new logic in mclient (i.e. possibly new ways to control the local audio buffer & new types of display data which need to be filtered out). So just to get mclient back to where we currently are requires a moderate to large amount of work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634923&aid=2008027&group_id=103474 |
From: SourceForge.net <no...@so...> - 2008-06-11 15:07:06
|
Bugs item #1990985, was opened at 2008-06-11 16:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=1990985&group_id=103474 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mvpmc - video player Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Simon Hyde (shyde) Assigned to: Nobody/Anonymous (nobody) Summary: Seek by percentage doesn't take into account buffering Initial Comment: Seeking by a percentage of file size doesn't take into account the current size/amount of data in any software buffers (or hardware buffers for that matter). This leads to jumping back 1% usually producing radically different results to forward 1%, for smaller files jumping back 1% can actually cause the video to jump forward (since 1% is less than the size of the buffer). Whilst I understand that taking into account the amount of data in the hardware buffer would be difficult (there's no known API for getting this, although it might be possible to do some estimation by comparing the STC with the PTS of the most recently seen video frame), checking the status of software buffers should be relatively easy, and could be factored into any calculations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=634920&aid=1990985&group_id=103474 |