hls playlist length

[ibizawold]

hello, i have set hls playlist length to 5h as basically i want to experiment by timeshifting of 5 hours.
The playlist creates the correct segments and includes #EXT-X-MEDIA-SEQUENCE:0

EXT-X-PLAYLIST-TYPE:EVENT but each time i open the stream is plays a few segments before the live position and not from the very first segment. Can anyone help or advise please

[kapilpendse]

@ibizawold Have you tried setting his_type to 'event'? The default is 'live'. Quoting from nginx-rtmp Wiki page:

Live HLS stream is usually played from the current live position which is several fragments to the end of playlist. Event HLS stream is always played from the start of playlist.

[ibizawold]

yes but still plays from live position ie approx 15secs from live feed

On 7 November 2016 at 02:44, Kapil Pendse notifications@github.com wrote:

@ibizawold https://github.com/ibizawold Have you tried setting his_type
to 'event'? The default is 'live'. Quoting from nginx-rtmp Wiki page:
https://github.com/arut/nginx-rtmp-module/wiki/Directives#hls_type

Live HLS stream is usually played from the current live position which is
several fragments to the end of playlist. Event HLS stream is always played
from the start of playlist.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#879 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALXSnMkhHPuKYEcp-jWvKWTug38_HopDks5q7pCogaJpZM4KHeJU
.

[kapilpendse]

Can you post your conf file?

On Monday 7 November 2016, ibizawold notifications@github.com wrote:

yes but still plays from live position ie approx 15secs from live feed

On 7 November 2016 at 02:44, Kapil Pendse <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

@ibizawold https://github.com/ibizawold Have you tried setting
his_type
to 'event'? The default is 'live'. Quoting from nginx-rtmp Wiki page:
https://github.com/arut/nginx-rtmp-module/wiki/Directives#hls_type

Live HLS stream is usually played from the current live position which is
several fragments to the end of playlist. Event HLS stream is always
played
from the start of playlist.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#879
issuecomment-258735458>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALXSnMkhHPuKYEcp-
jWvKWTug38_HopDks5q7pCogaJpZM4KHeJU>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#879 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAroy2HKK0J8b9rilsdUC2KDChholdTxks5q7xSfgaJpZM4KHeJU
.

[ibizawold]

This is part where instruct to use event;

worker_processes 1;
user root;
worker_rlimit_nofile 1024;

events {
worker_connections 1024;
multi_accept on;
}
rtmp_auto_push on;
rtmp {
server {
listen 1935;
chunk_size 8192;
idle_streams off;
application live {
live on;
wait_key on;
hls on;
hls_path /var/hls;
allow play all;
hls_type event;
include pull.conf;
}
}
}

On 7 November 2016 at 13:11, Kapil Pendse notifications@github.com wrote:

Can you post your conf file?

On Monday 7 November 2016, ibizawold notifications@github.com wrote:

yes but still plays from live position ie approx 15secs from live feed

On 7 November 2016 at 02:44, Kapil Pendse <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

@ibizawold https://github.com/ibizawold Have you tried setting
his_type
to 'event'? The default is 'live'. Quoting from nginx-rtmp Wiki page:
https://github.com/arut/nginx-rtmp-module/wiki/Directives#hls_type

Live HLS stream is usually played from the current live position which
is
several fragments to the end of playlist. Event HLS stream is always
played
from the start of playlist.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#879
issuecomment-258735458>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALXSnMkhHPuKYEcp-
jWvKWTug38_HopDks5q7pCogaJpZM4KHeJU>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#879
issuecomment-258819391>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AAroy2HKK0J8b9rilsdUC2KDChholdTxks5q7xSfgaJpZM4KHeJU>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#879 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALXSnHh39OHGviI_fLH_sRw1tqDjTkgdks5q7yNugaJpZM4KHeJU
.

[kapilpendse]

Ok, I ran some tests with a config similar to yours. I can reproduce the
issue you have reported. However, I think the problem might lie with the
player (client) rather than nginx-rtmp (or a combination of both).

The .m3u8 file generated by nginx-rtmp seems to be correct according to the
technical note on Apple website: http://goo.gl/DLSFBD

Perhaps with one exception though: even after the stream ended (I streamed
a short video file to nginx-rtmp HLS app, using ffmpeg), the m3u8 file was
not appended with EXT-X-ENDLIST. Now it is arguable if the nginx-rtmp
should add this to the file upon stream termination or not. In-bound
streams can get disconnected and may reconnect eventually.

Anyhow. I used hls.js to create a simple player. Upon playing the generated
m3u8 file, I noticed that the player was downloading and playing only the
last 2 or 3 fragments. This behaviour was consistent on Safari & Chrome
browsers. I opened the m3u8 file in a text editor and definitely the file
includes full list of fragments, not only the last few.

--snip--
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-TARGETDURATION:5
#EXT-X-PLAYLIST-TYPE: EVENT
#EXT-X-DISCONTINUITY
#EXTINF:5.015,
test-0.ts
#EXTINF:5.016,
test-1.ts
#EXTINF:5.015,
test-2.ts
...
#EXTINF:5.100,
test-74.ts
#EXTINF:0.200,
test-75.ts
--snip--

I verified this in browser debugger also. The m3u8 file downloaded by the
player indeed included full list of fragments, yet the player was
requesting download of only the last couple of fragments to play.

My final experiment was to hand edit the m3u8 file, to add #EXT-X-ENDLIST
at the end. And voila! The player now plays the file from beginning!
Although somehow the player now plays audio only which is quite strange,
but this might be an unrelated problem.

I will try to test more if I get time, but I hope these inputs help you
with your investigation. I suggest you try with some other HLS players. I
tried the bitmovin player (http://bitmovin.com/hls-mpeg-dash-test-player/)
also, and its behaviour is identical to hls.js.

Regards,

On Mon, Nov 7, 2016 at 9:47 PM, ibizawold notifications@github.com wrote:

This is part where instruct to use event;

worker_processes 1;
user root;
worker_rlimit_nofile 1024;

events {
worker_connections 1024;
multi_accept on;
}
rtmp_auto_push on;
rtmp {
server {
listen 1935;
chunk_size 8192;
idle_streams off;
application live {
live on;
wait_key on;
hls on;
hls_path /var/hls;
allow play all;
hls_type event;
include pull.conf;
}
}
}

On 7 November 2016 at 13:11, Kapil Pendse notifications@github.com
wrote:

Can you post your conf file?

On Monday 7 November 2016, ibizawold notifications@github.com wrote:

yes but still plays from live position ie approx 15secs from live feed

On 7 November 2016 at 02:44, Kapil Pendse <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

@ibizawold https://github.com/ibizawold Have you tried setting
his_type
to 'event'? The default is 'live'. Quoting from nginx-rtmp Wiki page:
https://github.com/arut/nginx-rtmp-module/wiki/Directives#hls_type

Live HLS stream is usually played from the current live position
which
is
several fragments to the end of playlist. Event HLS stream is always
played
from the start of playlist.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#879
issuecomment-258735458>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALXSnMkhHPuKYEcp-
jWvKWTug38_HopDks5q7pCogaJpZM4KHeJU>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#879
issuecomment-258819391>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AAroy2HKK0J8b9rilsdUC2KDChholdTxks5q7xSfgaJpZM4KHeJU>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#879
issuecomment-258831378>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALXSnHh39OHGviI_fLH_
sRw1tqDjTkgdks5q7yNugaJpZM4KHeJU>

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#879 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAroy8ogFDRxb_fB-JLjaljetgXz2rPMks5q7yvrgaJpZM4KHeJU
.

[ibizawold]

Hi
Thanks for your help with this;

I too had exactly same,

If we manually add #EXT-X-ENDLIST to playlist them upon reboot of nginx we
would be back to same problem again as playlist would be regenerated ?

thanks

On 8 November 2016 at 00:36, Kapil Pendse notifications@github.com wrote:

Ok, I ran some tests with a config similar to yours. I can reproduce the
issue you have reported. However, I think the problem might lie with the
player (client) rather than nginx-rtmp (or a combination of both).

The .m3u8 file generated by nginx-rtmp seems to be correct according to the
technical note on Apple website: http://goo.gl/DLSFBD

Perhaps with one exception though: even after the stream ended (I streamed
a short video file to nginx-rtmp HLS app, using ffmpeg), the m3u8 file was
not appended with EXT-X-ENDLIST. Now it is arguable if the nginx-rtmp
should add this to the file upon stream termination or not. In-bound
streams can get disconnected and may reconnect eventually.

Anyhow. I used hls.js to create a simple player. Upon playing the generated
m3u8 file, I noticed that the player was downloading and playing only the
last 2 or 3 fragments. This behaviour was consistent on Safari & Chrome
browsers. I opened the m3u8 file in a text editor and definitely the file
includes full list of fragments, not only the last few.

---

#EXTM3U

#EXT-X-VERSION:3

#EXT-X-MEDIA-SEQUENCE:0

#EXT-X-TARGETDURATION:5

#EXT-X-PLAYLIST-TYPE: EVENT

#EXT-X-DISCONTINUITY

#EXTINF:5.015,

test-0.ts

#EXTINF:5.016,

test-1.ts

#EXTINF:5.015,

test-2.ts
...

#EXTINF:5.100,

test-74.ts

#EXTINF:0.200,

test-75.ts

I verified this in browser debugger also. The m3u8 file downloaded by the
player indeed included full list of fragments, yet the player was
requesting download of only the last couple of fragments to play.

My final experiment was to hand edit the m3u8 file, to add #EXT-X-ENDLIST
at the end. And voila! The player now plays the file from beginning!
Although somehow the player now plays audio only which is quite strange,
but this might be an unrelated problem.

I will try to test more if I get time, but I hope these inputs help you
with your investigation. I suggest you try with some other HLS players. I
tried the bitmovin player (http://bitmovin.com/hls-mpeg-dash-test-player/)
also, and its behaviour is identical to hls.js.

Regards,

On Mon, Nov 7, 2016 at 9:47 PM, ibizawold notifications@github.com
wrote:

This is part where instruct to use event;

worker_processes 1;
user root;
worker_rlimit_nofile 1024;

events {
worker_connections 1024;
multi_accept on;
}
rtmp_auto_push on;
rtmp {
server {
listen 1935;
chunk_size 8192;
idle_streams off;
application live {
live on;
wait_key on;
hls on;
hls_path /var/hls;
allow play all;
hls_type event;
include pull.conf;
}
}
}

On 7 November 2016 at 13:11, Kapil Pendse notifications@github.com
wrote:

Can you post your conf file?

On Monday 7 November 2016, ibizawold notifications@github.com wrote:

yes but still plays from live position ie approx 15secs from live
feed

On 7 November 2016 at 02:44, Kapil Pendse <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

@ibizawold https://github.com/ibizawold Have you tried setting
his_type
to 'event'? The default is 'live'. Quoting from nginx-rtmp Wiki
page:
<https://github.com/arut/nginx-rtmp-module/wiki/
Directives#hls_type>

Live HLS stream is usually played from the current live position
which
is
several fragments to the end of playlist. Event HLS stream is
always
played
from the start of playlist.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#879
issuecomment-258735458>,
or mute the thread
<https://github.com/notifications/unsubscribe-
auth/ALXSnMkhHPuKYEcp-
jWvKWTug38_HopDks5q7pCogaJpZM4KHeJU>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#879
issuecomment-258819391>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AAroy2HKK0J8b9rilsdUC2KDChholdTxks5q7xSfgaJpZM4KHeJU>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#879
issuecomment-258831378>,
or mute the thread
<https://github.com/notifications/unsubscribe-
auth/ALXSnHh39OHGviI_fLH_
sRw1tqDjTkgdks5q7yNugaJpZM4KHeJU>

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#879
issuecomment-258839314>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAroy8ogFDRxb_fB-
JLjaljetgXz2rPMks5q7yvrgaJpZM4KHeJU>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#879 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALXSnFID7jRJ_0IHAvIGo9oqbRXiBsU0ks5q78P5gaJpZM4KHeJU
.

[kapilpendse]

Yes, if nginx-rtmp is to regenerate the m3u8 file after reboot, we'd be
back to the same problem.

I think this problem should be solved at client (player) end, not at
nginx-rtmp end. Let me explain why I say this. There is not good way for
nginx-rtmp to know when the event as ended, unless an assumption is made
that a input stream disconnection is to be treated as end of event. It may
be possible to register and handle the 'on_done' callback, and insert
the #EXT-X-ENDLIST in this callback. This would perhaps be more robust that
manually editing the generated m3u8 files.

The HLS specification at
https://tools.ietf.org/html/draft-pantos-http-live-streaming-20 does not
specify how a player should/must behave when it comes to playing 'EVENT'
type playlist. It seems most players play such a playlist as if it is a
LIVE playlist i.e. they start playing it from near the live edge instead of
from beginning. It appears to be a reasonable approach assuming that the
event is deferred live. The absence of #EXT-X-ENDLIST can be reasonably
interpreted as the event is still ongoing, and thus the user would most
likely want to see live footage. However, from my testing of this scenario,
the players don't offer any way for user to seek back to the beginning of
the event. I see this as a potential improvement that can be implemented at
player end.

Hope this helps.

On Tue, Nov 8, 2016 at 7:20 PM, ibizawold notifications@github.com wrote:

Hi
Thanks for your help with this;

I too had exactly same,

If we manually add #EXT-X-ENDLIST to playlist them upon reboot of nginx we
would be back to same problem again as playlist would be regenerated ?

thanks

On 8 November 2016 at 00:36, Kapil Pendse notifications@github.com
wrote:

Ok, I ran some tests with a config similar to yours. I can reproduce the
issue you have reported. However, I think the problem might lie with the
player (client) rather than nginx-rtmp (or a combination of both).

The .m3u8 file generated by nginx-rtmp seems to be correct according to
the
technical note on Apple website: http://goo.gl/DLSFBD

Perhaps with one exception though: even after the stream ended (I
streamed
a short video file to nginx-rtmp HLS app, using ffmpeg), the m3u8 file
was
not appended with EXT-X-ENDLIST. Now it is arguable if the nginx-rtmp
should add this to the file upon stream termination or not. In-bound
streams can get disconnected and may reconnect eventually.

Anyhow. I used hls.js to create a simple player. Upon playing the
generated
m3u8 file, I noticed that the player was downloading and playing only the
last 2 or 3 fragments. This behaviour was consistent on Safari & Chrome
browsers. I opened the m3u8 file in a text editor and definitely the file
includes full list of fragments, not only the last few.

---

#EXTM3U

#EXT-X-VERSION:3

#EXT-X-MEDIA-SEQUENCE:0

#EXT-X-TARGETDURATION:5

#EXT-X-PLAYLIST-TYPE: EVENT

#EXT-X-DISCONTINUITY

#EXTINF:5.015,

test-0.ts

#EXTINF:5.016,

test-1.ts

#EXTINF:5.015,

test-2.ts
...

#EXTINF:5.100,

test-74.ts

#EXTINF:0.200,

test-75.ts

I verified this in browser debugger also. The m3u8 file downloaded by the
player indeed included full list of fragments, yet the player was
requesting download of only the last couple of fragments to play.

My final experiment was to hand edit the m3u8 file, to add #EXT-X-ENDLIST
at the end. And voila! The player now plays the file from beginning!
Although somehow the player now plays audio only which is quite strange,
but this might be an unrelated problem.

I will try to test more if I get time, but I hope these inputs help you
with your investigation. I suggest you try with some other HLS players. I
tried the bitmovin player (http://bitmovin.com/hls-mpeg-
dash-test-player/)
also, and its behaviour is identical to hls.js.

Regards,

On Mon, Nov 7, 2016 at 9:47 PM, ibizawold notifications@github.com
wrote:

This is part where instruct to use event;

worker_processes 1;
user root;
worker_rlimit_nofile 1024;

events {
worker_connections 1024;
multi_accept on;
}
rtmp_auto_push on;
rtmp {
server {
listen 1935;
chunk_size 8192;
idle_streams off;
application live {
live on;
wait_key on;
hls on;
hls_path /var/hls;
allow play all;
hls_type event;
include pull.conf;
}
}
}

On 7 November 2016 at 13:11, Kapil Pendse notifications@github.com
wrote:

Can you post your conf file?

On Monday 7 November 2016, ibizawold notifications@github.com
wrote:

yes but still plays from live position ie approx 15secs from live
feed

On 7 November 2016 at 02:44, Kapil Pendse <
notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

@ibizawold https://github.com/ibizawold Have you tried setting
his_type
to 'event'? The default is 'live'. Quoting from nginx-rtmp Wiki
page:
<https://github.com/arut/nginx-rtmp-module/wiki/
Directives#hls_type>

Live HLS stream is usually played from the current live position
which
is
several fragments to the end of playlist. Event HLS stream is
always
played
from the start of playlist.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#879
issuecomment-258735458>,
or mute the thread
<https://github.com/notifications/unsubscribe-
auth/ALXSnMkhHPuKYEcp-
jWvKWTug38_HopDks5q7pCogaJpZM4KHeJU>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#879
issuecomment-258819391>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AAroy2HKK0J8b9rilsdUC2KDChholdTxks5q7xSfgaJpZM4KHeJU>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#879
issuecomment-258831378>,
or mute the thread
<https://github.com/notifications/unsubscribe-
auth/ALXSnHh39OHGviI_fLH_
sRw1tqDjTkgdks5q7yNugaJpZM4KHeJU>

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#879
issuecomment-258839314>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAroy8ogFDRxb_fB-
JLjaljetgXz2rPMks5q7yvrgaJpZM4KHeJU>

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#879
issuecomment-259009396>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALXSnFID7jRJ_
0IHAvIGo9oqbRXiBsU0ks5q78P5gaJpZM4KHeJU>

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#879 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAroy7_ZOUh0q9rUIJAxIDIkSVZIKLOTks5q8FrpgaJpZM4KHeJU
.

[coditori]

According to the Apple documentation about Event mode, a m3u8 file should be like this:

#EXTM3U
#EXT-X-PLAYLIST-TYPE:EVENT
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:10,
fileSequence0.ts
#EXTINF:10,
fileSequence1.ts
#EXTINF:10,
fileSequence2.ts
#EXTINF:10,
fileSequence3.ts
#EXTINF:10,
fileSequence4.ts
...
#EXTINF:10,
fileSequence120.ts
#EXTINF:10,
fileSequence121.ts
#EXT-X-ENDLIST

So I think we absolutely need to add #EXT-X-ENDLIST at the end because they said

event playlists are typically used for events such as concerts or sports games where you want to allow the user to seek anywhere in the event from the beginning

That means in event mode we should have seek bar... So I think it's a bug fix issue

[kapilpendse]

Hello, I haven't worked with nginx-rtmp lately, so I might be a bit rusty. Quoting from the same Apple documentation link: "An event playlist looks just like a live playlist to start out with. It doesn't initially have an EXT-X-ENDLIST tag, indicating that new media files will be added to the playlist as they become available." My interpretation of this is that event playlist must have EXT-X-ENDLIST only at the end i.e. only when the input stream has definitively ended. The nginx-rtmp module would have to be able to know the difference between end of input stream and abrupt disconnection of input stream. Only then it will be able to decide whether to append the EXT-X-ENDLIST or not. I believe this type of decision is best implemented by an application outside of nginx-rtmp or an event handling script. Regards, Kapil

…

On Sat, 4 Feb 2017 at 2:59 AM, Massoud Afrashteh ***@***.***> wrote: According to the Apple documentation <https://developer.apple.com/library/content/technotes/tn2288/_index.html#//apple_ref/doc/uid/DTS40012238-CH1-EVENT_PLAYLIST> about Event mode, a m3u8 file should be like this: #EXTM3U #EXT-X-PLAYLIST-TYPE:EVENT #EXT-X-TARGETDURATION:10 #EXT-X-MEDIA-SEQUENCE:0 #EXTINF:10, fileSequence0.ts #EXTINF:10, fileSequence1.ts #EXTINF:10, fileSequence2.ts #EXTINF:10, fileSequence3.ts #EXTINF:10, fileSequence4.ts ... #EXTINF:10, fileSequence120.ts #EXTINF:10, fileSequence121.ts #EXT-X-ENDLIST So I think we absolutely need to add #EXT-X-ENDLIST at the end because they said event playlists are typically used for events such as concerts or sports games where you want to allow the user to seek anywhere in the event from the beginning That means in event mode we should have seek bar... So I think it's a bug fix issue — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#879 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAroy-uih6pE9OJLlhJzZeTVvoY9H78Gks5rY3kmgaJpZM4KHeJU> .

[emanspeaks]

As a workaround to this, I wrote the following script called fixhls.sh:

#!/bin/bash

NGINXROOT=/home/nginx
HLSROOT=$NGINXROOT/hls

streamdir=$HLSROOT/$1
playlist=$streamdir/index.m3u8

chmod 775 $streamdir
chmod -R g+w $streamdir
echo "#EXT-X-ENDLIST" >> $playlist

I then added the following to my nginx.conf: exec_publish_done /home/nginx/fixhls.sh $name;

This fixed both this issue as well as addresses the directory permissions until #1494 is merged (though note that I also wanted to add group write in addition to the change in that request)