[17:48] superm1: tgm4883 mrand dmfrey wants to report a bug for the user's groups, where should that go [17:49] the users group? [17:50] just wanted to see if dialout could be added to the main users groups by default [17:50] he says it should be in the dial out group for access to libcec [17:50] libcec is for access to the usb cec adapters [17:51] i also noticed that the ChannelIcons storage group is not being created, so no channel icons are downloading [17:51] is that a new storage group? [17:51] I don't remember that one [17:52] i was looking into why my channel icons weren't showing on new 12.04 backend install [17:52] i guess they used to be in ~.mythtv/channels [17:53] but the documentation seems to indicate they should now be in (in mythbuntu) /var/lib/mythtv/channels and mythfrontend looks for them in the Storage group ChannelIcons [17:53] Bugs go at https://bugs.launchpad.net/mythbuntu/+filebug [17:53] [bugs.launchpad.net] OpenID transaction in progress [17:53] why does libcec need dialout? [17:54] that is the group the /dev/ttyACM0 device gets created into [17:54] pulse-eight usb cec adapter [17:54] Does that group make sense for that device? [17:57] secondly, does the device need to be accessed by the frontend or backend? [17:59] not sure if it makes sense, i will ask in the pulse-eight channel if that is preferred [17:59] it is accessed in the frontend [17:59] if you don't have libcec installed, you usually see 'cecadapter.cpp:128 (Open) CECAdapter: Failed to load libcec.' in the logs [18:06] dmfrey: does the backend user need to be in it or the frontend user? [18:06] superm1, sounds like frontend user [18:06] frontend [18:07] dmfrey: hmm well the default user ubuntu creates gets put in the dialout group [18:09] weird, mine wasn't in there [18:09] this was a fresh install from sunday night [18:16] i check both my machines, fresh install from sunday night and monday morning, one is x86_64, other is 32 pae and neither have dialout in the groups [18:16] hmm weird, what did you install from? [18:16] mythbuntu ISO or ubuntu ISO or ubuntu server ISO [18:19] mythbuntu iso [18:37] hmm weird [18:43] ok, i had to not only add libcec but libcec-dev to get mythfrontend to recognize that libcec was installed [18:46] went looking through the cecadapter.cpp and saw the libcec headers it was trying to load which were not on my system [18:46] installing the dev package fixed that [19:00] dmfrey, I think I'm too invested in this email thread for a project I don't even work on [19:02] tgm4883: welcome aboard [19:04] rhpot1991, yea, I'm kinda tired of people that demand things for free [19:05] I'm tired of visual studio crashing [19:07] rhpot1991, shoot me now, haven't looked at visual studio in over 10 years :) [19:07] tgm4883, yeah, i am not sure what he thinks that will do that something like mythexport doesn't already do [19:08] plus the app would in essence have to watch the program for your in order to download and store, it would still need to kick off a hls stream [19:08] my last email pretty much says it is not gonna do it [19:08] dmfrey, I think he just wants it more integrated, which would probably be great, but would require a lot more on the app side and probably still be clunky [19:08] yea my last email basically says patches probably welcome [19:09] I misunderstood what he was asking I guess [19:09] I though the wanted to access recordings without transcoding [19:10] the problem with local storage is that its anti HLS too [19:10] rhpot1991, he doesn't want to wait for transcoding [19:10] so no mythexport, yes HLS [19:10] in theory we could prob wget it all, modify the playlist and have it pull from local [19:10] i am not sure that you could record the hls stream to a file in java anyway [19:10] playlist isn't done until the transcoding is done too [19:10] dmfrey, could you just store the file chunks? [19:10] so you can't pull till everything is done [19:11] as rhpot1991 said, store the m3u8 file, alter it for local playback of the file chunks, and be on your way? [19:12] not a great solution due to things I just said though [19:12] rhpot1991, I don't like the timeframe of it, taking super long to actually get the files needed [19:12] rhpot1991, I think it's perfectly fine though size wise [19:12] tgm4883, i don't think so, since they are offloaded to an external player [19:13] tgm4883: ya I thought he wanted no transcoding which leads to huge files [19:13] dmfrey, well what do you do right now? You download the m3u8 file and hand it to VIDPLAYER? [19:13] rhpot1991, no he wants HLS to transcode it [19:13] tgm4883: ya [19:13] get the playlist via the api call [19:13] rhpot1991, even then, except for nexus devices I don't think size matters ;) [19:13] pump that to the player [19:13] who handles the rest [19:14] tgm4883: well even if you max out with a 32gb card [19:14] thats maybe 2-3 large recordings [19:14] I was going to explore doing some local non transcoding with google tv possibly [19:14] rhpot1991, I think that is probably all you need, but if you HLS transcode it you should get more [19:14] if you are local and it can handle your content no reason you need ot transcode [19:15] rhpot1991, dmfrey so what if you download the m3u8 file to a cache dir, edit it, then hand it over to VIDPLAYER? [19:15] tgm4883: its built as the transcoding happens I believe [19:15] so you'd have to wait till all transcoding was done [19:15] get it then, modify, use [19:15] but soon they will be introducing an ondemand hls [19:15] ondemand? [19:15] you will literally be able to jump to a specific spot in the program [19:16] isn't it already on demand? [19:16] ah [19:16] it will all be coded into the rest endpoint [19:16] that will be nice :) [19:16] including video size, bitrate, etc [19:16] then you could do what netflix does I'm guessing [19:16] adjusting bitrate on the fly? [19:16] pretty much [19:16] could possibly [19:16] until i see it, i am not sure [19:16] probably be in on .27 [19:17] I'm assuming there is still file storage though on the backend for HLS transcodes [19:17] if not .28 [19:17] i assume so. in the streaming storage group [19:18] now that i think about it, we could probably make the app kick off a hls stream, so that it pre-transcodes on the backend, then you can come to it whenever you want [19:18] right now we start it, wait, then play it [19:18] when done, we kill the stream [19:18] on the backend [19:19] yea I think the main issue is the transcoding time [19:19] could almost implement a watch it later feature so it is already transcoded on the backend [19:19] then should be able to ff and rew [19:19] that might be something to think about [19:19] i gotta get my data loading issues solved first [19:20] so its not so slow for people [19:20] dmfrey, if you did a watch it later feature, you could make that a prerequiset of 'download locally" [19:20] true [19:21] so with the data loading issues, you are pulling the entire schedule? [19:21] not sure if the myth services api allows for downloading the .m3u8 files themselves [19:21] the first time through, i load each day at a time, then parse it to a db [19:21] is that really necessary? [19:21] that is for implementing a youtube like search from the action bar [19:22] hmm [19:22] like mythweb does it [19:22] i don't want to be constantly accessing the the backend [19:22] my thought now is to download hour chunks and store them as json [19:23] use that for the program guide when you page through the hours and days from local files [19:23] dmfrey, well, I only think you need it locally if you want to have offline searching [19:23] which I don't think is needed [19:23] implement etag into them so i know when data changes to redownload a chunk here and there [19:23] what if there was a services API for searching the schedule? [19:23] i didn't find one [19:24] right, I meant if one was added [19:24] maybe it will be added, but don't think that is available now [19:24] probably right [19:24] similar to the "list titles" being unavailable [19:25] in the /Guide services, you can get the program guide, get details for a particular program, or the channel icon [19:25] yeah [19:25] maybe in the /Dvr GetFilteredProgramList, but that might be for just what you have recorded already [19:25] yea that is just what is recorded already [19:26] and that returns way too much info IMO [19:26] so, following android design guidelines, download data locally, store in content provider, only access network when needed [19:27] ah [19:27] pretty much to save battery, etc. [19:27] that changes things [19:27] global search needs content provider [19:27] so if i keep the files locally, i can use them, parse them when needed, etc. [19:27] setup alarm tasks to delete old stuff [19:28] and, once etag is publicly available, can use that to determine of the network resource changed and only download when needed [19:29] i like json for local storage because i can parse that in java much faster than xml [19:30] plus for the program guide i put in the latest version, the data is already structured in the format i need to move through that pager [19:31] and have been reading up on managing some caches of files for quicker ui/ux response [19:31] could prove to be quite a fast interface [19:32] so basically when you start the app, start downloading the data chunks in the background and let you do whatever you want in the app [19:32] right, which makes sense [19:32] however, you will only be able see the data up to the point where you downloaded it [19:32] which i think is acceptable [19:32] which I think is reasonable [19:32] since it will eventually fill in everything [19:35] exactly [19:35] so probably just grab the more often used stuff first [19:35] probably schedules last [19:36] right [19:49] ignore where type == reality tv [19:49] populate with breaking bad instead [19:49] :) [23:17] hello