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