Thank you for your donation!


Official moOde 6.5.1 support thread
#61
The upcoming 6.5.2 update fixes the Spotify issue on arm6.
#62
(04-30-2020, 02:09 PM)bitlab Wrote: Upgrading from 6.4.2 to 6.5.1 I noticed that I can see less albums at once in the album view.

The difference on my systems in available rows x columns thumbnails:
         tablet     pc
6.4.2   3.0x7     3.6x8
6.5.1   2.5x6     2.8x7

Is there a way how you can influence the scaling in 6.5.x ?

Thanks,
Marcel

ps found that changing panel.min.css does the trick (from thumbcols:16vw  to thumbcols:12vw), but not sure if that does have other unwanted side effects ?

What make and model are the tablets and do you know their viewport sizes?
#63
I had an issue of UI freeze (or almost):
1. search in library view. After type some text hit ENTER key.

At this time, if I click on an result album, nothing will happen.

If I do not hit ENTER and just move over and click on an album, it works just fine.

I'm using a Linux PC with latest Chrome. On my pixel phone I also experience the same problem. I cannot hit equivalent of ENTER.

Also, I like the old UI where search field is just there, not in a drop down. But this is minor.
#64
The enter key is only needed for submitting the special year or year range search. This is explained in Quick help. If not doing the year search then as you enter the search string a type down search will be performed on the album list. Type down search is also used for the Playlist and Radio list.

I am able to repro the enter key issue though and will investigate.
#65
Wink 
(04-30-2020, 10:01 PM)Tim Curtis Wrote: The enter key is only needed for submitting the special year or year range search. This is explained in Quick help. If not doing the year search then as you enter the search string a type down search will be performed on the album list. Type down search is also used for the Playlist and Radio list.

I am able to repro the enter key issue though and will investigate.

hit ENTER is a habit and a little hard to avoid sometimesSmile Thanks for the reply.
#66
For sure :-)

I suspect a bug though. The enter key on a non year search should not cause any issues.
#67
@duracell80
@Tim Curtis

I'm not sure where this discussion of podcasts is going.

I thought the original post http://moodeaudio.org/forum/showthread.p...2#pid19422 was concerned with the seekbar wonkiness in v6.5.1 which has been discussed elsewhere and is being resolved.

The podcast illustrated in the image in that post is indeed a file with a title and a duration of 36-odd minutes (e.g., 2212 sec) as the #EXTINF line in the .m3u file declared. It's the seekbar wonkiness which makes it look strange in the image.  

As previously noted, these MP3 podcasts are not streams of an infinite number of MP3 frames ala a radio station but rather what some call "MP3-on-demand" in which the server is "streaming" the finite number of MP3 frames from an MP3 file rather than offering the MP3 file for download.

As for the apparent 0 time duration of a true MP3 stream, see the MPD plugin which parses .m3u files. From src/playlist/plugins/EXTM3uPlaylistPlugin.cxx, this snippet shows MPD forces any negative value to zero before anything else sees it.


Code:
/**
* Parse a EXTINF line.
*
* @param line the rest of the input line after the colon
*/
static Tag
extm3u_parse_tag(const char *line)
{
    long duration;
    char *endptr;
    const char *name;

    duration = strtol(line, &endptr, 10);
    if (endptr[0] != ',')
        /* malformed line */
        return Tag();

    if (duration < 0)
        /* 0 means unknown duration */
        duration = 0;

In any case, M3U has no formal specification and the use of -1 to indicate a stream seems to be a convention. In example 1 of the Wikipedia article on M3U is found

Quote:A length of -1 or 0 may be used when the media file is a streaming file, as there is no actual, predefined length value.


Just my 2-cents worth.

Regards,
Kent
#68
I dunno about the -1 thing but these particular http streams have some attributes that don't have a case in the code yet so they are incorrectly seen as song files and thus the wonky timeline and time knob.

They are streaming sources and so for now should prolly should just be displayed same as radio station rather than try to add logic to treat them as song files.
#69
I'm still not sure I get it. What would be the expected screen display for a podcast?

When I feed duracell80's sample .m3u file to VLC, it starts playing the first "song" and displays the duration and title it grabs from the corresponding #EXTINF line. Isn't that what moOde is trying to do, putting aside the known seekbar issue? The only thing extra I see is the "Streaming Source" label which is kinda true.

The bottom line for me is that these podcasts are neither fish nor fowl when streaming so it's not surprising they are an edge case.

I wonder what happens if the URL in the .m3u file resolves to a file on a real file server?

Regards,
Kent
#70
After thinking about it I dunno if podcasts are worth trying to do any coding for them. They are not music from what I can tell.


Forum Jump: